- Infra - oVirt List Archives

[JIRA] (OVIRT-1797) restart an OST suite at specific point (for development)
by Greg Sheremeta (oVirt JIRA) 10 Dec '17

10 Dec '17

This is a multi-part message in MIME format... ------------=_1512909059-20475-151 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1797?page=com.atlassian.jira.… ] Greg Sheremeta commented on OVIRT-1797: --------------------------------------- Moved to https://ovirt-jira.atlassian.net/browse/OST-87 > restart an OST suite at specific point (for development) > -------------------------------------------------------- > > Key: OVIRT-1797 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1797 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST > Reporter: Greg Sheremeta > Assignee: infra > > I would like an easy way (perhaps a lago command) to restart an OST suite at 00x rather than running the whole thing and waiting 10-30 minutes per code change test, which is unbearable when I'm trying to iterate on something while developing. > I found this, but it doesn't work for me. > https://gist.githubusercontent.com/nvgoldin/e5046659a6ea7f002f890e7aafc62f6… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074) ------------=_1512909059-20475-151 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1797?page=com.atlassian.jira.… ]</pre> <h3>Greg Sheremeta commented on OVIRT-1797:</h3> Moved to <a href="https://ovirt-jira.atlassian.net/browse/OST-87">https://ovirt-jira.atlassian.net/browse/OST-87</a> <blockquote><h3>restart an OST suite at specific point (for development)</h3> <pre> Key: OVIRT-1797 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1797 Project: oVirt - virtualization made easy Issue Type: Improvement Components: OST Reporter: Greg Sheremeta Assignee: infra</pre> I would like an easy way (perhaps a lago command) to restart an OST suite at 00x rather than running the whole thing and waiting 10-30 minutes per code change test, which is unbearable when I'm trying to iterate on something while developing. I found this, but it doesn't work for me. <a href="https://gist.githubusercontent.com/nvgoldin/e5046659a6ea7f002f890e7aafc62f6…">https://gist.githubusercontent.com/nvgoldin/e5046659a6ea7f002f890e7aafc62f6…</a></blockquote> — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074) <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> ------------=_1512909059-20475-151--

1 0

[JIRA] (OVIRT-1797) restart an OST suite at specific point (for development)
by Greg Sheremeta (oVirt JIRA) 10 Dec '17

10 Dec '17

Greg Sheremeta created OVIRT-1797: ------------------------------------- Summary: restart an OST suite at specific point (for development) Key: OVIRT-1797 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1797 Project: oVirt - virtualization made easy Issue Type: Improvement Components: OST Reporter: Greg Sheremeta Assignee: infra I would like an easy way (perhaps a lago command) to restart an OST suite at 00x rather than running the whole thing and waiting 10-30 minutes per code change test, which is unbearable when I'm trying to iterate on something while developing. I found this, but it doesn't work for me. https://gist.githubusercontent.com/nvgoldin/e5046659a6ea7f002f890e7aafc62f6… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100074)

1 0

[ OST Failure Report ] [ oVirtMaster ] [ 07-11-2017 ] [007_sd_reattach.deactivate_storage_domain ]
by Dafna Ron 10 Dec '17

10 Dec '17

This is a multi-part message in MIME format. --------------B1FC8E7562A08FCCC455CECC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, We had a failure on master basic suite for test 007_sd_reattach.deactivate_storage_domain. The failure was that we failed to deactivate domain due to running tasks. It does not seem to be related to the patch it was testing and I think that the test itself needs to be modified to check there are no running tasks. Is there perhaps a way to query if there are running tasks before running the command? can you please take a look at the test on OST? ** *Link and headline of suspected patches:**Not related to error*** ** ** *Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/* *** Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/artifact/ (Relevant) error snippet from the log: <error> *2017-12-06 20:13:23,166-05 WARN [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Validation of action 'DeactivateStorageDomainWithOvfUpdate' fa iled for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS 2017-12-06 20:13:23,167-05 INFO [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Lock freed to object 'EngineLock:{exclusiveLocks='[ea2fd992-8a a4-44fe-aa43-e96754a975ba=STORAGE]', sharedLocks='[5e0a0183-0e25-4f43-b5b0-0cfb5510248e=POOL]'}' 2017-12-06 20:13:23,172-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] method: runAction, params: [DeactivateStorageDomainWithOvfUpdate, DeactivateSto rageDomainWithOvfUpdateParameters:{commandId='630c28e1-41ab-43db-9755-a2bb870dbcb3', user='null', commandType='Unknown'}], timeElapsed: 65ms 2017-12-06 20:13:23,176-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-7) [] Operation Failed: [Cannot deactivate Storage while there are running tasks on this Storage. -Please wait until tasks will finish and try again.] * *<error> --------------B1FC8E7562A08FCCC455CECC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, We had a failure on master basic suite for test 007_sd_reattach.deactivate_storage_domain. The failure was that we failed to deactivate domain due to running tasks. It does not seem to be related to the patch it was testing and I think that the test itself needs to be modified to check there are no running tasks. Is there perhaps a way to query if there are running tasks before running the command? can you please take a look at the test on OST? <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link and headline of suspected patches: Not related to error <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to Job: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/</a> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to all logs: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/artifact/">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/artifact/</a> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">(Relevant) error snippet from the log: <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"><error> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">2017-12-06 20:13:23,166-05 WARN [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Validation of action 'DeactivateStorageDomainWithOvfUpdate' fa iled for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS 2017-12-06 20:13:23,167-05 INFO [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Lock freed to object 'EngineLock:{exclusiveLocks='[ea2fd992-8a a4-44fe-aa43-e96754a975ba=STORAGE]', sharedLocks='[5e0a0183-0e25-4f43-b5b0-0cfb5510248e=POOL]'}' 2017-12-06 20:13:23,172-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] method: runAction, params: [DeactivateStorageDomainWithOvfUpdate, DeactivateSto rageDomainWithOvfUpdateParameters:{commandId='630c28e1-41ab-43db-9755-a2bb870dbcb3', user='null', commandType='Unknown'}], timeElapsed: 65ms 2017-12-06 20:13:23,176-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-7) [] Operation Failed: [Cannot deactivate Storage while there are running tasks on this Storage. -Please wait until tasks will finish and try again.] <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> <error> </body> </html> --------------B1FC8E7562A08FCCC455CECC--

4 9

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

10 Dec '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1772: -------------------------------- Blocked By: Code review Status: Blocked (was: In Progress) > 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#100074)

1 0

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

10 Dec '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1772: ------------------------------------- An s390x VM has been added as a slave to both Jenkins instances. When linked patches are merged s390x support for oVirt CI will be ready for use by any oVirt project. Now blocking ticket on code review. > 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#100074)

1 0

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

10 Dec '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1772: -------------------------------- Status: In Progress (was: To Do) > 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#100074)

1 0

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

10 Dec '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1772?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1772: ------------------------------------- Current direction for implementing support is to use a loaned slave managed by Dan Horak. This requires patching STDCI code to be able to run on a slave where we don't have full sudo privileges, as well as adding some new mock_runner configuration. Patches implementing these two things have been implemented and tested. (Linked to this ticket) > 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#100074)

1 0

Change in stage-stdci1[master]: Make separate files for all CI stages
by review＠gerrit-staging.phx.ovirt.org 09 Dec '17

09 Dec '17

>From Barak Korren <bkorren(a)redhat.com>: Barak Korren has posted comments on this change. ( https://gerrit-staging.phx.ovirt.org/69 ) Change subject: Make separate files for all CI stages ...................................................................... Patch Set 1: ci please build -- To view, visit https://gerrit-staging.phx.ovirt.org/69 To unsubscribe, visit https://gerrit-staging.phx.ovirt.org/settings Gerrit-Project: stage-stdci1 Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I21e93c31d26799db0d7d69cc3c830094f7ac8e63 Gerrit-Change-Number: 69 Gerrit-PatchSet: 1 Gerrit-Owner: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Jenkins CI <infra(a)ovirt.org> Gerrit-Comment-Date: Sat, 09 Dec 2017 22:55:40 +0000 Gerrit-HasComments: No

1 0

Change in stage-stdci1[master]: Make separate files for all CI stages
by review＠gerrit-staging.phx.ovirt.org 09 Dec '17

09 Dec '17

>From Barak Korren <bkorren(a)redhat.com>: Barak Korren has posted comments on this change. ( https://gerrit-staging.phx.ovirt.org/69 ) Change subject: Make separate files for all CI stages ...................................................................... Patch Set 1: ci build please -- To view, visit https://gerrit-staging.phx.ovirt.org/69 To unsubscribe, visit https://gerrit-staging.phx.ovirt.org/settings Gerrit-Project: stage-stdci1 Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I21e93c31d26799db0d7d69cc3c830094f7ac8e63 Gerrit-Change-Number: 69 Gerrit-PatchSet: 1 Gerrit-Owner: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Jenkins CI <infra(a)ovirt.org> Gerrit-Comment-Date: Sat, 09 Dec 2017 22:55:06 +0000 Gerrit-HasComments: No

1 0

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

09 Dec '17

------=_Part_335_1854774325.1512701170985 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.1/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.1/115/ Build Number: 115 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #115 [Yaniv Kaul] Remove unneeded dep (Windows VC redist package). -4MB to sync... [Yedidyah Bar David] wgt: Fix excludes [Anton Marchukov] Enabled repoman builds on Fedora 27. ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_335_1854774325.1512701170985--

1 1