- Infra - oVirt List Archives

[oVirt Jenkins] ovirt-system-tests_hc-basic-suite-master - Build # 114 - Failure!
by jenkins＠jenkins.phx.ovirt.org 09 Dec '17

09 Dec '17

------=_Part_265_154552158.1512442724885 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/114/ Build Number: 114 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #114 [Yaniv Kaul] Set OvfUpdateIntervalInMinutes=10 for oVirt System Test suite. [Gal Ben Haim] kubevirt-ansible: Adding github pipeline [Martin Sivak] Cleanup the job for ovirt-optimizer ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_265_154552158.1512442724885--

1 4

[JIRA] (OVIRT-1788) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Barak Korren (oVirt JIRA) 08 Dec '17

08 Dec '17

This is a multi-part message in MIME format... ------------=_1512763653-17340-252 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1788: ------------------------------------- {quote} Perhaps just use old versions of the container? Example: https://github.com/SeleniumHQ/docker-selenium/releases/tag/3.4.0-einsteinium uses Firefox 54 {quote} Yep. This is what Docker tags are for... In fact, we should probably set things up so that we always use specific tagged versions in tests rather then '{{:latest}}', so that we don't introduce a rouge source of change to our testing apparatus. > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OVIRT-1788 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST > Reporter: Greg Sheremeta > Assignee: infra > > I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. > The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. > Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. > Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074) ------------=_1512763653-17340-252 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren commented on OVIRT-1788:</h3> <p>{quote} Perhaps just use old versions of the container? Example: <a href="https://github.com/SeleniumHQ/docker-selenium/releases/tag/3.4.0-einsteinium">https://github.com/SeleniumHQ/docker-selenium/releases/tag/3.4.0-einsteinium</a> uses Firefox 54 {quote}</p> <p>Yep. This is what Docker tags are for…</p> <p>In fact, we should probably set things up so that we always use specific tagged versions in tests rather then ‘{{:latest}}’, so that we don't introduce a rouge source of change to our testing apparatus.</p> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OVIRT-1788 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788 Project: oVirt - virtualization made easy Issue Type: Improvement Components: OST Reporter: Greg Sheremeta Assignee: infra</pre> <p>I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.)</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074)</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> ------------=_1512763653-17340-252--

1 0

[JIRA] (OVIRT-1788) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Greg Sheremeta (oVirt JIRA) 08 Dec '17

08 Dec '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jira.… ] Greg Sheremeta commented on OVIRT-1788: --------------------------------------- One issue I see is that the provided containers use only the latest browser. Example: https://github.com/SeleniumHQ/docker-selenium/blob/master/NodeFirefox/Docke… ARG FIREFOX_VERSION=57.0.1 Any ideas on how we could use older browsers too? Perhaps just use old versions of the container? Example: https://github.com/SeleniumHQ/docker-selenium/releases/tag/3.4.0-einsteinium uses Firefox 54 > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OVIRT-1788 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST > Reporter: Greg Sheremeta > Assignee: infra > > I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. > The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. > Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. > Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074)

1 0

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #986
by jenkins＠jenkins.phx.ovirt.org 08 Dec '17

08 Dec '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/986/displa…> Changes: [Anton Marchukov] Enabled repoman builds on Fedora 27. ------------------------------------------ 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 9c4d074e30ec2f38daa27431716bc75d33eb8fbe (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 9c4d074e30ec2f38daa27431716bc75d33eb8fbe Commit message: "Enabled repoman builds on Fedora 27." > git rev-list b8d7eb1564528a26affca81548a5f84249e690aa # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins357930039576039284.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

[CQ]: 84787,3 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 07 Dec '17

07 Dec '17

Change 84787,3 (ovirt-engine) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/84787/3 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4331/

1 0

oVirt infra weekly meeting notes 06.12.2017
by Evgheni Dereveanchin 07 Dec '17

07 Dec '17

Hi everyone, Please find the topics of this week's infra meeting below: PHX DC: - Overview of infra and documentation <http://ovirt-infra-docs.readthedocs.io/> - PHX upgrade to 4.2 progressing <https://ovirt-jira.atlassian.net/browse/OVIRT-1735>, some more bugs identified - Status.ovirt.org moved to OpenShift AI: - Add a link to Jira on this <http://ovirt-infra-docs.readthedocs.io/en/latest/General/Communication/inde…> page - patch <https://gerrit.ovirt.org/#/c/85190/> - Find some entry level tickets to assign to volunteers - Backup persistent data on OpenShift? - Move all web hosting to Openshift? Candidates: - www.ovirt.org - stats.ovirt.org - templates.ovirt.org -- Regards, Evgheni Dereveanchin

1 0

[JIRA] (OVIRT-1788) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Barak Korren (oVirt JIRA) 07 Dec '17

07 Dec '17

This is a multi-part message in MIME format... ------------=_1512641905-10461-119 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1788: ------------------------------------- [~gshereme(a)redhat.com] I don't know enough about how to use Selenium to iterate on this on my own, so I'll try to guide you through what I think is needed to be done. If you want more hand-on help from me, you'll need to teach me a little about Selenium and perhaps give me a small example app I can iterate with... Here are the things that need to be done # Enable the OST suit to use docker - this is done by: ## Adding '{{docker}}' to the '{{*.packages}}' file of the suit ## Adding '{{docker}}' to the '{{*.packages}}' file of '{{check-patch}}' (So code changes to the suit can be tested). ## Add the following to the relevant '{{*.mounts}}' files {code}/var/run/docker.sock:/var/run/docker.sock{code} # Start up the Selenium containers from inside the suit and make them able to talk to oVirt. The readme of the GitHub repo gives examples of '{{docker}}' commands doing that, but those use the deprecated '{{--link}}' option. I've looked at what the containers actually do, and is seems that the browser containers simply expect the '{{HUB_PORT_4444_TCP_ADDR}}' and '{{HUB_PORT_4444_TCP_PORT}}' environment variables to be defined for them and pointing to the hub container. A more modern approach to setting this up would be: ## Setup a Docker network to connect the containers together ## Setup the hostnames for the oVirt VMs in the Docker network ## Start up a hub container and expose port 4444 so test suits can connect to it. ## Start up the browser containers and configure the env vars for then so they can find the hub container The above could be done with a bunch of Docker commands, but a better approach would be to use an automation tool such as '{{docker-compose}}'. But given that Ansible is closer to home for us, and likely to be used by other oVirt components, I think '{{ansible-containers}}' would be a better choice here. > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OVIRT-1788 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST > Reporter: Greg Sheremeta > Assignee: infra > > I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. > The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. > Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. > Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074) ------------=_1512641905-10461-119 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren commented on OVIRT-1788:</h3> <p>[~gshereme(a)redhat.com] I don't know enough about how to use Selenium to iterate on this on my own, so I'll try to guide you through what I think is needed to be done. If you want more hand-on help from me, you'll need to teach me a little about Selenium and perhaps give me a small example app I can iterate with…</p> <p>Here are the things that need to be done # Enable the OST suit to use docker – this is done by: ## Adding ‘{{docker}}’ to the ‘{{*.packages}}’ file of the suit ## Adding ‘{{docker}}’ to the ‘{{*.packages}}’ file of ‘{{check-patch}}’ (So code changes to the suit can be tested). ## Add the following to the relevant ‘{{*.mounts}}’ files</p> <pre>{code}/var/run/docker.sock:/var/run/docker.sock{code}</pre> <p># Start up the Selenium containers from inside the suit and make them able to talk to oVirt. The readme of the GitHub repo gives examples of ‘{{docker}}’ commands doing that, but those use the deprecated ‘{{--link}}’ option. I've looked at what the containers actually do, and is seems that the browser containers simply expect the ‘{{HUB_PORT_4444_TCP_ADDR}}’ and ‘{{HUB_PORT_4444_TCP_PORT}}’ environment variables to be defined for them and pointing to the hub container. A more modern approach to setting this up would be: ## Setup a Docker network to connect the containers together ## Setup the hostnames for the oVirt VMs in the Docker network ## Start up a hub container and expose port 4444 so test suits can connect to it. ## Start up the browser containers and configure the env vars for then so they can find the hub container</p> <pre>The above could be done with a bunch of Docker commands, but a better approach would be to use an automation tool such as '{{docker-compose}}'. But given that Ansible is closer to home for us, and likely to be used by other oVirt components, I think '{{ansible-containers}}' would be a better choice here.</pre> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OVIRT-1788 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788 Project: oVirt - virtualization made easy Issue Type: Improvement Components: OST Reporter: Greg Sheremeta Assignee: infra</pre> <p>I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.)</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074)</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> ------------=_1512641905-10461-119--

1 0

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #984
by jenkins＠jenkins.phx.ovirt.org 07 Dec '17

07 Dec '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/984/displa…> Changes: [Yedidyah Bar David] wgt: Fix excludes ------------------------------------------ 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 b8d7eb1564528a26affca81548a5f84249e690aa (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f b8d7eb1564528a26affca81548a5f84249e690aa Commit message: "wgt: Fix excludes" > git rev-list bd4aab54d0c2d8ee1df391e2bcc82634ff73ff01 # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins4889443385421125569.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 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-updates-el7 error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7' Build step 'Execute shell' marked build as failure

1 1

Build failed in Jenkins: system-sync_mirrors-fedora-base-fcraw-x86_64 #189
by jenkins＠jenkins.phx.ovirt.org 07 Dec '17

07 Dec '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-base-fcraw-x86_64/1…> ------------------------------------------ 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-fedora-base-fcraw-x86_64/w…> > 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 bd4aab54d0c2d8ee1df391e2bcc82634ff73ff01 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f bd4aab54d0c2d8ee1df391e2bcc82634ff73ff01 Commit message: "ovirt-wgt: Exclude Fedora in 4.2 branch" > git rev-list bd4aab54d0c2d8ee1df391e2bcc82634ff73ff01 # timeout=10 [system-sync_mirrors-fedora-base-fcraw-x86_64] $ /bin/bash -xe /tmp/jenkins2492263899277715568.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror fedora-base-fcraw x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Resyncing repo: fedora-base-fcraw Syncing yum repo fedora-base-fcraw for arch: x86_64 fedora-base-fcraw/group 37% [=====- ] 0.0 B/s | 696 kB --:-- ETA fedora-base-fcraw/group | 1.8 MB 00:00 gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch.r FAILED gold-2.1.12.2-24.fc27.noar 0% [ ] 0.0 B/s | 0 B --:-- ETA gold-2.1.12.2-24.fc27.noarch: [Errno 256] No more mirrors to try. Build step 'Execute shell' marked build as failure

1 2

[ANN] oVirt 4.2.0 First Candidate Release is now available for testing
by Sandro Bonazzola 07 Dec '17

07 Dec '17

The oVirt Project is pleased to announce the availability of the First Candidate Release of oVirt 4.2.0, as of December 5th, 2017 This is pre-release software. This pre-release should not to be used in production. Please take a look at our community page[1] to learn how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This update is the first candidate release of the 4.2.0 version. This release brings more than 280 enhancements and more than one thousand bug fixes, including more than 500 high or urgent severity fixes, on top of oVirt 4.1 series. What's new in oVirt 4.2.0? - The Administration Portal has been completely redesigned using Patternfly, a widely adopted standard in web application design. It now features a cleaner, more intuitive design, for an improved user experience. - There is an all-new VM Portal for non-admin users. - A new High Performance virtual machine type has been added to the New VM dialog box in the Administration Portal. - Open Virtual Network (OVN) adds support for Open vSwitch software defined networking (SDN). - oVirt now supports Nvidia vGPU. - The ovirt-ansible-roles set of packages help users with common administration tasks. - Virt-v2v now supports Debian/Ubuntu based VMs. For more information about these and other features, check out the oVirt 4.2.0 blog post <https://ovirt.org/blog/2017/11/introducing-ovirt-4.2.0-beta/> and stay tuned for further blog post. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 (available for x86_64 only) See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available. - oVirt Node is already available [4] Additional Resources: * Read more about the oVirt 4.2.0 release highlights: http://www.ovirt.org/release/4.2.0/ * 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] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.2.0/ [4] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/ -- 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>

2 1