- Infra - oVirt List Archives

oVirt infra weekly meeting notes 15.11.2017
by Evgheni Dereveanchin 19 Nov '17

19 Nov '17

Hi everyone, Please find the topics of this week's infra meeting below: PHX DC: - HyperConverged - rebuilt with RPMs from Master - nested KVM hook installed - running VMs attached to Staging - Jenkins - upgrade to 2.73.3 planned OVIRT-1760 <https://ovirt-jira.atlassian.net/browse/OVIRT-1760> - optimize Garbage collection to speed up Jenkins OVIRT-1756 <https://ovirt-jira.atlassian.net/browse/OVIRT-1756> - disk extend attempted but has problems OVIRT-1765 <https://ovirt-jira.atlassian.net/browse/OVIRT-1765> - CI slowdown due to some OST jobs not running in RAM OVIRT-1763 <https://ovirt-jira.atlassian.net/browse/OVIRT-1763> - Fedora 27 release - decommission/upgrade most FC25 systems - add FC27 mirror for “updates” repo OVIRT-1708 <https://ovirt-jira.atlassian.net/browse/OVIRT-1708> Action Items: - Try running Jenkins with our plugins on OpenShift - Add fc24+fc25 to Staging Jenkins -- Regards, Evgheni Dereveanchin

2 1

[JIRA] (OVIRT-1772) s390x build support for oVirt infra
by Barak Korren (oVirt JIRA) 19 Nov '17

19 Nov '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1772: -------------------------------- Description: There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. Here is a list of things we would need in order to enable s390x builds: * Bring up some s390x Jenkins slave VMs, this implies: ** Getting s390x VMs up and running ** Getting an operating system for these VMs ** Getting Java running on these VMs, in order to run the Jenkins agent. * Enable '{{mock_runner.sh}}' to create s390x build environments. * Create '{{build-artifacts}}' jobs for s390x The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: {code} <guest> <os_type>hvm</os_type> <arch name='s390x'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-s390x</emulator> <machine maxCpus='255'>s390-virtio</machine> <machine canonical='s390-virtio' maxCpus='255'>s390</machine> <machine maxCpus='255'>s390-ccw-virtio</machine> <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> <domain type='qemu'/> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default='on' toggle='no'/> </features> </guest> {code} So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we may end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. Once we have VMs up, we need to turn them into Jenkins slaves. Hopefully the s390x Fedora build includes Java so this may be trivial. To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. was: There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. Here is a list of things we would need in order to enable s390x builds: * Bring up some s390x Jenkins slave VMs, this implies: ** Getting s390x VMs up and running ** Getting an operating system for these VMs ** Getting Java running on these VMs, in order to run the Jenkins agent. * Enable '{{mock_runner.sh}}' to create s390x build environments. * Create '{{build-artifacts}}' jobs for s390x The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: {code} <guest> <os_type>hvm</os_type> <arch name='s390x'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-s390x</emulator> <machine maxCpus='255'>s390-virtio</machine> <machine canonical='s390-virtio' maxCpus='255'>s390</machine> <machine maxCpus='255'>s390-ccw-virtio</machine> <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> <domain type='qemu'/> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default='on' toggle='no'/> </features> </guest> {code} So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we have end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. Once we have VMs up, we need to turn them into Jenkins slaves. Hopefully the s390x Fedora build includes Java so this may be trivial. To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. > s390x build support for oVirt infra > ----------------------------------- > > Key: OVIRT-1772 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1772 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: s390x, standard-ci > > There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. > Here is a list of things we would need in order to enable s390x builds: > * Bring up some s390x Jenkins slave VMs, this implies: > ** Getting s390x VMs up and running > ** Getting an operating system for these VMs > ** Getting Java running on these VMs, in order to run the Jenkins agent. > * Enable '{{mock_runner.sh}}' to create s390x build environments. > * Create '{{build-artifacts}}' jobs for s390x > The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: > {code} > <guest> > <os_type>hvm</os_type> > <arch name='s390x'> > <wordsize>64</wordsize> > <emulator>/usr/bin/qemu-system-s390x</emulator> > <machine maxCpus='255'>s390-virtio</machine> > <machine canonical='s390-virtio' maxCpus='255'>s390</machine> > <machine maxCpus='255'>s390-ccw-virtio</machine> > <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> > <domain type='qemu'/> > </arch> > <features> > <cpuselection/> > <deviceboot/> > <disksnapshot default='on' toggle='no'/> > </features> > </guest> > {code} > So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we may end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. > Once we have VMs up, we need to turn them into Jenkins slaves. Hopefully the s390x Fedora build includes Java so this may be trivial. > To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. > Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100071)

1 0

[JIRA] (OVIRT-1772) s390x build support for oVirt infra
by Barak Korren (oVirt JIRA) 19 Nov '17

19 Nov '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1772: -------------------------------- Description: There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. Here is a list of things we would need in order to enable s390x builds: * Bring up some s390x Jenkins slave VMs, this implies: ** Getting s390x VMs up and running ** Getting an operating system for these VMs ** Getting Java running on these VMs, in order to run the Jenkins agent. * Enable '{{mock_runner.sh}}' to create s390x build environments. * Create '{{build-artifacts}}' jobs for s390x The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: {code} <guest> <os_type>hvm</os_type> <arch name='s390x'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-s390x</emulator> <machine maxCpus='255'>s390-virtio</machine> <machine canonical='s390-virtio' maxCpus='255'>s390</machine> <machine maxCpus='255'>s390-ccw-virtio</machine> <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> <domain type='qemu'/> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default='on' toggle='no'/> </features> </guest> {code} So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we have end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. Once we have VMs up, we need to turn them into Jenkins slaves. Hopefully the s390x Fedora build includes Java so this may be trivial. To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. was: There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. Here is a list of things we would need in order to enable s390x builds: * Bring up some s390x Jenkins slave VMs, this implies: ** Getting s390x VMs up and running ** Getting an operating system for these VMs ** Getting Java running on these VMs, in order to run the Jenkins agent. * Enable '{{mock_runner.sh}}' to create s390x build environments. * Create '{{build-artifacts}}' jobs for s390x The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: {code} <guest> <os_type>hvm</os_type> <arch name='s390x'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-s390x</emulator> <machine maxCpus='255'>s390-virtio</machine> <machine canonical='s390-virtio' maxCpus='255'>s390</machine> <machine maxCpus='255'>s390-ccw-virtio</machine> <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> <domain type='qemu'/> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default='on' toggle='no'/> </features> </guest> {code} So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we have end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. Once we have VMs up, we need to turn them into Jenkins slaves, hopefully the s390x Fedora build includes Java, so this me be trivial. To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. > s390x build support for oVirt infra > ----------------------------------- > > Key: OVIRT-1772 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1772 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: s390x, standard-ci > > There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. > Here is a list of things we would need in order to enable s390x builds: > * Bring up some s390x Jenkins slave VMs, this implies: > ** Getting s390x VMs up and running > ** Getting an operating system for these VMs > ** Getting Java running on these VMs, in order to run the Jenkins agent. > * Enable '{{mock_runner.sh}}' to create s390x build environments. > * Create '{{build-artifacts}}' jobs for s390x > The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: > {code} > <guest> > <os_type>hvm</os_type> > <arch name='s390x'> > <wordsize>64</wordsize> > <emulator>/usr/bin/qemu-system-s390x</emulator> > <machine maxCpus='255'>s390-virtio</machine> > <machine canonical='s390-virtio' maxCpus='255'>s390</machine> > <machine maxCpus='255'>s390-ccw-virtio</machine> > <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> > <domain type='qemu'/> > </arch> > <features> > <cpuselection/> > <deviceboot/> > <disksnapshot default='on' toggle='no'/> > </features> > </guest> > {code} > So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we have end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. > Once we have VMs up, we need to turn them into Jenkins slaves. Hopefully the s390x Fedora build includes Java so this may be trivial. > To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. > Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100071)

1 0

[JIRA] (OVIRT-1772) s390x build support for oVirt infra
by Barak Korren (oVirt JIRA) 19 Nov '17

19 Nov '17

Barak Korren created OVIRT-1772: ----------------------------------- Summary: s390x build support for oVirt infra Key: OVIRT-1772 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1772 Project: oVirt - virtualization made easy Issue Type: Improvement Components: oVirt CI Reporter: Barak Korren Assignee: infra There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. Here is a list of things we would need in order to enable s390x builds: * Bring up some s390x Jenkins slave VMs, this implies: ** Getting s390x VMs up and running ** Getting an operating system for these VMs ** Getting Java running on these VMs, in order to run the Jenkins agent. * Enable '{{mock_runner.sh}}' to create s390x build environments. * Create '{{build-artifacts}}' jobs for s390x The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: {code} <guest> <os_type>hvm</os_type> <arch name='s390x'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-s390x</emulator> <machine maxCpus='255'>s390-virtio</machine> <machine canonical='s390-virtio' maxCpus='255'>s390</machine> <machine maxCpus='255'>s390-ccw-virtio</machine> <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> <domain type='qemu'/> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default='on' toggle='no'/> </features> </guest> {code} So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we have end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. Once we have VMs up, we need to turn them into Jenkins slaves, hopefully the s390x Fedora build includes Java, so this me be trivial. To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100071)

1 0

[JIRA] (OVIRT-1772) s390x build support for oVirt infra
by Barak Korren (oVirt JIRA) 19 Nov '17

19 Nov '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1772: -------------------------------- Epic Link: OVIRT-400 > s390x build support for oVirt infra > ----------------------------------- > > Key: OVIRT-1772 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1772 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: s390x, standard-ci > > There has been some recent interest in the community lately in building oVirt node components for the s390x architecture. > Here is a list of things we would need in order to enable s390x builds: > * Bring up some s390x Jenkins slave VMs, this implies: > ** Getting s390x VMs up and running > ** Getting an operating system for these VMs > ** Getting Java running on these VMs, in order to run the Jenkins agent. > * Enable '{{mock_runner.sh}}' to create s390x build environments. > * Create '{{build-artifacts}}' jobs for s390x > The easiest way get s390x slave VMs would be if we could get our hands on some real s390x machines, just like the ppc64le machines we currently have. But this does not seem to be likely to happen. An alternative would be to use some kind of s390x emulation. This kind of emulation seems to be used by the Fedora project for their s390x builds. A version of qemu that supports s390x is available in EPEL in the '{{qemu-system-s390x}}' package. Once installed, the package adds the following libvirt capabilities structure: > {code} > <guest> > <os_type>hvm</os_type> > <arch name='s390x'> > <wordsize>64</wordsize> > <emulator>/usr/bin/qemu-system-s390x</emulator> > <machine maxCpus='255'>s390-virtio</machine> > <machine canonical='s390-virtio' maxCpus='255'>s390</machine> > <machine maxCpus='255'>s390-ccw-virtio</machine> > <machine canonical='s390-ccw-virtio' maxCpus='255'>s390-ccw</machine> > <domain type='qemu'/> > </arch> > <features> > <cpuselection/> > <deviceboot/> > <disksnapshot default='on' toggle='no'/> > </features> > </guest> > {code} > So it seems we can get s390x VMs running on our x86_64 hardware. The next issue to tackle would be to get an OS running on these VMs. The seems to be a Fedora s390x release but not a CentOS one. Neither of these projects release an s390x cloud image, so we have end up having to make our own using '{{virt-install}}' or try to convince [Richard Jones|mailto:rjones@redhat.com] to make such images available in '{{virt-builder}}'. > Once we have VMs up, we need to turn them into Jenkins slaves, hopefully the s390x Fedora build includes Java, so this me be trivial. > To get '{{mock_runner.sh}}' support we would need an appropriates '{{mock}}' configuration files. Suitable files for Fedora on s390x package seems to already be shipped with the '{{mock}}' package, so there is not much to do there besides copying the file into our '{{jenkins}}' repo and making the usual adjustments we typically make to enable proxy and mirrors support. > Once we have all of that up and running, adding s390x '{{build-artifacts}}' jobs would be trivial, we'll just have to add the right tags in the JJB YAML. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100071)

1 0

Jenkins build became unstable: ovirt_master_publish-rpms_nightly #776
by jenkins＠jenkins.phx.ovirt.org 19 Nov '17

19 Nov '17

See <http://jenkins.ovirt.org/job/ovirt_master_publish-rpms_nightly/776/display/…>

1 1

oVirt infra daily report - unstable production jobs - 509
by jenkins＠jenkins.phx.ovirt.org 18 Nov '17

18 Nov '17

------=_Part_364_706569487.1511046003177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Good morning! Attached is the HTML page with the jenkins status report. You can see it also here: - http://jenkins.ovirt.org/job/system_jenkins-report/509//artifact/exported-a… Cheers, Jenkins ------=_Part_364_706569487.1511046003177 Content-Type: text/html; charset=us-ascii; name=upstream_report.html Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=upstream_report.html Content-ID: <upstream_report.html> <!DOCTYPE html><head><style type="text/css"> table.gridtable { border-collapse: collapse; table-layout:fixed; width:1600px; font-family: monospace; font-size:13px; } .head { font-size:20px; font-family: arial; } .sub { font-size:18px; background-color:#e5e5e5; font-family: arial; } pre { font-family: monospace; display: inline; white-space: pre-wrap; white-space: -moz-pre-wrap !important; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word; } </style> </head> <body> <table class="gridtable" border=2> <tr><th colspan=2 class=head> RHEVM CI Jenkins Daily Report - 18/11/2017 </th></tr><tr><th colspan=2 class=sub> <font color="blue"><a href="http://jenkins.ovirt.org/">00 Unstable Critical</a></font> </th></tr> ------=_Part_364_706569487.1511046003177--

1 0

Build failed in Jenkins: system-sync_mirrors-fedora-updates-fc26-x86_64 #376
by jenkins＠jenkins.phx.ovirt.org 18 Nov '17

18 Nov '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-updates-fc26-x86_64…> ------------------------------------------ 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-updates-fc26-x86_64…> > 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 c848618cd96aca191eeb7b18ccb24a8bdea486e7 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f c848618cd96aca191eeb7b18ccb24a8bdea486e7 Commit message: "Remove 4.0 and 3.6 builds from MOM" > git rev-list c848618cd96aca191eeb7b18ccb24a8bdea486e7 # timeout=10 [system-sync_mirrors-fedora-updates-fc26-x86_64] $ /bin/bash -xe /tmp/jenkins2902470939292923607.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror fedora-updates-fc26 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 1479, in _commonLoadRepoXML result = self._getFileRepoXML(local, text) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1256, in _getFileRepoXML size=102400) # setting max size as 100K File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1039, in _getFile raise e yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from fedora-updates-fc26: [Errno 256] No more mirrors to try. http://mirror.cc.vt.edu/pub/fedora/linux/updates/26/x86_64/repodata/repomd.…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://fedora.mirror.constant.com/fedora/linux/updates/26/x86_64/repodata/…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirrors.rit.edu/fedora/fedora/linux/updates/26/x86_64/repodata/repo…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://pubmirror2.math.uh.edu/fedora-buffet/fedora/linux/updates/26/x86_64…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://pubmirror1.math.uh.edu/fedora-buffet/fedora/linux/updates/26/x86_64…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://mirror.cs.pitt.edu/fedora/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://mirror.sjc02.svwh.net/fedora/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirror.us-midwest-1.nexcess.net/fedora/updates/26/x86_64/repodata/r…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://download-ib01.fedoraproject.org/pub/fedora/linux/updates/26/x86_64/…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://mirror.uoregon.edu/fedora/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://mirror.rnet.missouri.edu/fedora/updates/26/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found https://mirror.mrjester.net/fedora/linux/updates/26/x86_64/repodata/repomd.…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirror.chpc.utah.edu/pub/fedora/linux/updates/26/x86_64/repodata/re…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirrors.xmission.com/fedora/linux/updates/26/x86_64/repodata/repomd…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://repo.atlantic.net/fedora/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://linux.mirrors.es.net/fedora/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirror.umd.edu/fedora/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirrors.kernel.org/fedora/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://ftp.usf.edu/pub/fedora/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirror.vcu.edu/pub/gnu+linux/fedora/updates/26/x86_64/repodata/repo…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://kdeforge2.unl.edu/mirrors/fedora/linux/updates/26/x86_64/repodata/re…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://dl.fedoraproject.org/pub/fedora/linux/updates/26/x86_64/repodata/re…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://mirror.csclub.uwaterloo.ca/fedora/linux/updates/26/x86_64/repodata/…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 https://muug.ca/mirror/fedora/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://fedora.mirror.iweb.com/linux/updates/26/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://fedora.bhs.mirrors.ovh.net/linux/updates/26/x86_64/repodata/repomd.x…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 http://mirrors.syringanetworks.net/fedora/linux/updates/26/x86_64/repodata/…: [Errno -1] repomd.xml does not match metalink for fedora-updates-fc26 Build step 'Execute shell' marked build as failure

1 1

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #924
by jenkins＠jenkins.phx.ovirt.org 18 Nov '17

18 Nov '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/924/displa…> ------------------------------------------ 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 c848618cd96aca191eeb7b18ccb24a8bdea486e7 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f c848618cd96aca191eeb7b18ccb24a8bdea486e7 Commit message: "Remove 4.0 and 3.6 builds from MOM" > git rev-list c848618cd96aca191eeb7b18ccb24a8bdea486e7 # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins5622117276060250494.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 112, in retrieveAllMD repo._revertOldRepoXML() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1331, in _revertOldRepoXML os.rename(old_data['old_local'], old_data['local']) OSError: [Errno 2] No such file or directory Build step 'Execute shell' marked build as failure

1 1

[CQ]: 84133,4 (ovirt-imageio) failed "ovirt-master" system tests
by oVirt Jenkins 18 Nov '17

18 Nov '17

Change 84133,4 (ovirt-imageio) 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/84133/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3902/

1 0