March 2018 - Infra - oVirt List Archives

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA) 06 Mar '18

06 Mar '18

This is a multi-part message in MIME format... ------------=_1520333776-20649-136 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:56 AM: -------------------------------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This is the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081) ------------=_1520333776-20649-136 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:56 AM:</h3> <p>{quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This is the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p> <p>was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p> <blockquote><h3>Single project tests in change-queue-tester</h3> <pre> Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra</pre> <p>Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>></p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1520333776-20649-136--

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA) 06 Mar '18

06 Mar '18

This is a multi-part message in MIME format... ------------=_1520333757-27720-121 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM: -------------------------------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081) ------------=_1520333757-27720-121 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM:</h3> <p>{quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p> <p>was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX.</p> <blockquote><h3>Single project tests in change-queue-tester</h3> <pre> Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra</pre> <p>Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>></p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1520333757-27720-121--

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1918: ------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by sbonazzo (oVirt JIRA) 06 Mar '18

06 Mar '18

sbonazzo created OVIRT-1918: ------------------------------- Summary: Single project tests in change-queue-tester Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again "ci re-merge please" again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #1262
by jenkins＠jenkins.phx.ovirt.org 06 Mar '18

06 Mar '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/1262/displ…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision ea02d358e4b5ba495ce4f865f48d932427cd0bdb (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f ea02d358e4b5ba495ce4f865f48d932427cd0bdb Commit message: "Revert "Install base packeges and start services from global_setup"" > git rev-list --no-walk ea02d358e4b5ba495ce4f865f48d932427cd0bdb # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins562107027827444518.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror epel-el6 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1474, in _commonLoadRepoXML if self._latestRepoXML(local): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1443, in _latestRepoXML oxml = self._saveOldRepoXML(local) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1300, in _saveOldRepoXML shutil.copy2(local, old_local) File "/usr/lib64/python2.7/shutil.py", line 131, in copy2 copystat(src, dst) File "/usr/lib64/python2.7/shutil.py", line 98, in copystat os.utime(dst, (st.st_atime, st.st_mtime)) OSError: [Errno 2] No such file or directory: '/home/jenkins/mirrors_cache/centos-extras-el7/repomd.xml.old.tmp' Build step 'Execute shell' marked build as failure

1 1

[JIRA] (OVIRT-1917) Off by one bug in nested config parser
by Daniel Belenky (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1917?page=com.atlassian.jira.… ] Daniel Belenky reassigned OVIRT-1917: ------------------------------------- Assignee: Daniel Belenky (was: infra) > Off by one bug in nested config parser > -------------------------------------- > > Key: OVIRT-1917 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1917 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: Daniel Belenky > Priority: Highest > > There is an off by one bug in _cartesian_multiplication() (nested_config.py) where if given a list of vectors to try and merge with each other, the last vector, if merged, needs to be excluded from the final result since it was already merged. In other cases, if the last vector was not merged, it needs to be included in the final result. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

[JIRA] (OVIRT-1917) Off by one bug in nested config parser
by Daniel Belenky (oVirt JIRA) 06 Mar '18

06 Mar '18

Daniel Belenky created OVIRT-1917: ------------------------------------- Summary: Off by one bug in nested config parser Key: OVIRT-1917 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1917 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Daniel Belenky Assignee: infra Priority: Highest There is an off by one bug in _cartesian_multiplication() (nested_config.py) where if given a list of vectors to try and merge with each other, the last vector, if merged, needs to be excluded from the final result since it was already merged. In other cases, if the last vector was not merged, it needs to be included in the final result. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

[CQ]: 88501, 3 (ovirt-engine-metrics) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 06 Mar '18

06 Mar '18

A system test invoked by the "ovirt-master" change queue including change 88501,3 (ovirt-engine-metrics) failed. However, this change seems not to be the root cause for this failure. Change 88250,4 (ovirt-engine-metrics) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 88250,4 (ovirt-engine-metrics) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/88501/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/88250/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6075/

1 0

[JIRA] (OVIRT-1861) Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available
by sbonazzo (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1861?page=com.atlassian.jira.… ] sbonazzo updated OVIRT-1861: ---------------------------- Component/s: wiki (MediaWiki) > Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available > ------------------------------------------------------------ > > Key: OVIRT-1861 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1861 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: wiki (MediaWiki) > Reporter: sbonazzo > Assignee: infra > > 2018-01-24 13:47 GMT+01:00 Arman Khalatyan <arm2arm(a)gmail.com>: > > Thanks for the announcement. > > A little comment: could you please fix the line yum install > > <http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm > > <http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm%3E> > > There is an extra '<' symbol there since 4.0.x :=) > > > > > Thanks for the feedback, I opened > https://github.com/oVirt/ovirt-site/issues/1503 to track this. > Opening a ticket on infra as well for further investigations. > > > > On Wed, Jan 24, 2018 at 12:00 PM, Lev Veyde <lveyde(a)redhat.com> wrote: > > > >> The oVirt Project is pleased to announce the availability of the oVirt > >> 4.1.9 release, as of January 24th, 2017 > >> > >> This update is the ninth in a series of stabilization updates to the 4.1 > >> series. > >> > >> Please note that no further updates will be issued for the 4.1 series. > >> We encourage users to upgrade to 4.2 series to receive new features and > >> updates. > >> > >> This release is available now for: > >> * Red Hat Enterprise Linux 7.4 or later > >> * CentOS Linux (or similar) 7.4 or later > >> > >> This release supports Hypervisor Hosts running: > >> * Red Hat Enterprise Linux 7.4 or later > >> * CentOS Linux (or similar) 7.4 or later > >> * oVirt Node 4.1 > >> > >> See the release notes [1] for installation / upgrade instructions and > >> a list of new features and bugs fixed. > >> > >> Notes: > >> - oVirt Appliance is already available > >> - oVirt Live is already available [2] > >> - oVirt Node will be available soon [2] > >> > >> Additional Resources: > >> * Read more about the oVirt 4.1.9 release highlights:http://www.ovirt.or > >> g/release/4.1.9/ > >> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt > >> * Check out the latest project news on the oVirt blog: > >> http://www.ovirt.org/blog/ > >> > >> [1] http://www.ovirt.org/release/4.1.9/ > >> [2] http://resources.ovirt.org/pub/ovirt-4.1/iso/ > >> > >> -- > >> > >> Lev Veyde > >> > >> Software Engineer, RHCE | RHCVA | MCITP > >> > >> Red Hat Israel > >> > >> <https://www.redhat.com> > >> > >> lev(a)redhat.com | lveyde(a)redhat.com > >> <https://red.ht/sig> > >> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > >> > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

[JIRA] (OVIRT-1861) Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available
by sbonazzo (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1861?page=com.atlassian.jira.… ] sbonazzo updated OVIRT-1861: ---------------------------- Issue Type: Bug (was: By-EMAIL) > Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available > ------------------------------------------------------------ > > Key: OVIRT-1861 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1861 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: sbonazzo > Assignee: infra > > 2018-01-24 13:47 GMT+01:00 Arman Khalatyan <arm2arm(a)gmail.com>: > > Thanks for the announcement. > > A little comment: could you please fix the line yum install > > <http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm > > <http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm%3E> > > There is an extra '<' symbol there since 4.0.x :=) > > > > > Thanks for the feedback, I opened > https://github.com/oVirt/ovirt-site/issues/1503 to track this. > Opening a ticket on infra as well for further investigations. > > > > On Wed, Jan 24, 2018 at 12:00 PM, Lev Veyde <lveyde(a)redhat.com> wrote: > > > >> The oVirt Project is pleased to announce the availability of the oVirt > >> 4.1.9 release, as of January 24th, 2017 > >> > >> This update is the ninth in a series of stabilization updates to the 4.1 > >> series. > >> > >> Please note that no further updates will be issued for the 4.1 series. > >> We encourage users to upgrade to 4.2 series to receive new features and > >> updates. > >> > >> This release is available now for: > >> * Red Hat Enterprise Linux 7.4 or later > >> * CentOS Linux (or similar) 7.4 or later > >> > >> This release supports Hypervisor Hosts running: > >> * Red Hat Enterprise Linux 7.4 or later > >> * CentOS Linux (or similar) 7.4 or later > >> * oVirt Node 4.1 > >> > >> See the release notes [1] for installation / upgrade instructions and > >> a list of new features and bugs fixed. > >> > >> Notes: > >> - oVirt Appliance is already available > >> - oVirt Live is already available [2] > >> - oVirt Node will be available soon [2] > >> > >> Additional Resources: > >> * Read more about the oVirt 4.1.9 release highlights:http://www.ovirt.or > >> g/release/4.1.9/ > >> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt > >> * Check out the latest project news on the oVirt blog: > >> http://www.ovirt.org/blog/ > >> > >> [1] http://www.ovirt.org/release/4.1.9/ > >> [2] http://resources.ovirt.org/pub/ovirt-4.1/iso/ > >> > >> -- > >> > >> Lev Veyde > >> > >> Software Engineer, RHCE | RHCVA | MCITP > >> > >> Red Hat Israel > >> > >> <https://www.redhat.com> > >> > >> lev(a)redhat.com | lveyde(a)redhat.com > >> <https://red.ht/sig> > >> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > >> > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0