November 2017 - Infra - oVirt List Archives

[ OST Failure Report ] [ oVirt Master ] [ 06-11-2017 ] [ 002_bootstrap.verify_add_hosts ]
by Dafna Ron 07 Nov '17

07 Nov '17

This is a multi-part message in MIME format. --------------88DD9FCD3B3DDEA34D4EAEF4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, We failed test 002_bootstrap.verify_add_hosts I can see we only tried to install one of the hosts (host-0) and failed. the second host has no log which means we did not try to deploy it. The error suggests that we ovirt-imageio-daemon failed to start. However, there is another message that I think should be addressed about conflicting vdsm and libvirt configurations. ** *Link to suspected patches: https://gerrit.ovirt.org/#/c/83612/* * Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/ Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifact/ http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifact… * * *(Relevant) error snippet from the log: * * <error> \* 2017-11-06 02:56:46,526-0500 DEBUG otopi.plugins.ovirt_host_deploy.vdsm.packages plugin.execute:921 execute-output: ('/usr/bin/vdsm-tool', 'configure', '--force') stdout: Checking configuration status... abrt is not configured for vdsm WARNING: LVM local configuration: /etc/lvm/lvmlocal.conf is not based on vdsm configuration lvm requires configuration libvirt is not configured for vdsm yet FAILED: conflicting vdsm and libvirt-qemu tls configuration. vdsm.conf with ssl=True requires the following changes: libvirtd.conf: listen_tcp=0, auth_tcp="sasl", listen_tls=1 qemu.conf: spice_tls=1. multipath requires configuration 2017-11-06 02:56:47,551-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'ovirt-imageio-daemon.service') stderr: Job for ovirt-imageio-daemon.service failed because the control process exited with error code. See "systemctl status ovirt-imageio-daemon.service" and "journalctl -xe" for details. 2017-11-06 02:56:47,552-0500 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/tmp/ovirt-R4R8gZhaQI/pythonlib/otopi/context.py", line 133, in _executeMethod method['method']() File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/ovirt-host-deploy/vdsm/packages.py", line 179, in _start self.services.state('ovirt-imageio-daemon', True) File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/otopi/services/systemd.py", line 141, in state service=name, RuntimeError: Failed to start service 'ovirt-imageio-daemon' 2017-11-06 02:56:47,553-0500 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Closing up': Failed to start service 'ovirt-imageio-daemon' ** *</error>* * * --------------88DD9FCD3B3DDEA34D4EAEF4 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 failed test 002_bootstrap.verify_add_hosts I can see we only tried to install one of the hosts (host-0) and failed. the second host has no log which means we did not try to deploy it. The error suggests that we ovirt-imageio-daemon failed to start. However, there is another message that I think should be addressed about conflicting vdsm and libvirt configurations. <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 suspected patches: <a class="moz-txt-link-freetext" href="https://gerrit.ovirt.org/#/c/83612/">https://gerrit.ovirt.org/#/c/83612/</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 Job: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/</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/3626/artifact/">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/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;"> <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifact…">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/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> \ <pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">2017-11-06 02:56:46,526-0500 DEBUG otopi.plugins.ovirt_host_deploy.vdsm.packages plugin.execute:921 execute-output: ('/usr/bin/vdsm-tool', 'configure', '--force') stdout: Checking configuration status... abrt is not configured for vdsm WARNING: LVM local configuration: /etc/lvm/lvmlocal.conf is not based on vdsm configuration lvm requires configuration libvirt is not configured for vdsm yet FAILED: conflicting vdsm and libvirt-qemu tls configuration. vdsm.conf with ssl=True requires the following changes: libvirtd.conf: listen_tcp=0, auth_tcp="sasl", listen_tls=1 qemu.conf: spice_tls=1. multipath requires configuration </pre> <pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">2017-11-06 02:56:47,551-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'ovirt-imageio-daemon.service') stderr: Job for ovirt-imageio-daemon.service failed because the control process exited with error code. See "systemctl status ovirt-imageio-daemon.service" and "journalctl -xe" for details. 2017-11-06 02:56:47,552-0500 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/tmp/ovirt-R4R8gZhaQI/pythonlib/otopi/context.py", line 133, in _executeMethod method['method']() File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/ovirt-host-deploy/vdsm/packages.py", line 179, in _start self.services.state('ovirt-imageio-daemon', True) File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/otopi/services/systemd.py", line 141, in state service=name, RuntimeError: Failed to start service 'ovirt-imageio-daemon' 2017-11-06 02:56:47,553-0500 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Closing up': Failed to start service 'ovirt-imageio-daemon'</pre> <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> --------------88DD9FCD3B3DDEA34D4EAEF4--

5 7

[JIRA] (OVIRT-1743) ci please build and send to OST
by danken (oVirt JIRA) 07 Nov '17

07 Nov '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1743?page=com.atlassian.jira.… ] danken commented on OVIRT-1743: ------------------------------- If OST was cheap and quick, it would be lovely to run on any patch. It can also be run after a +2 from a maintainer, or after a workflow+1, providing a verified +0.5 to a patch. I don't know if that's what you're aiming at. > ci please build and send to OST > ------------------------------- > > Key: OVIRT-1743 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1743 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: change-queue > > Can you please automate the frequent process, which is slow and error prone? > I am writing a patch, and would like to test it in ost. now I need to > * "ci please build" > * copy el7 url > * wait for el7 build to finish > * copy artifacts url to ovirt--system-test-manual, start it > * copy the ost run URL to the gerrit patch, so I have it for reference of failure/success. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)

1 0

[JIRA] (OVIRT-1746) Make stand-alone upstream source collection and updating tool
by Barak Korren (oVirt JIRA) 07 Nov '17

07 Nov '17

This is a multi-part message in MIME format... ------------=_1510046714-26505-534 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1746?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1746: ----------------------------------- Assignee: Barak Korren (was: infra) > Make stand-alone upstream source collection and updating tool > ------------------------------------------------------------- > > Key: OVIRT-1746 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: Barak Korren > Labels: poll-upstream-sources, upstream-source-collector > > The upstream source collection code is currently built included in two different files - "{{upstream-source-collector.py}}" and "{{poll-upstream-sources.py}}". The files reside in "{{jobs/confs/python-scripts}}" which in turn mean they are mean for embedding into jobs by JJB. > This situation causes several issues: > # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally > # There is code duplication between the two python scripts > # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example) > # It is impossible to use the code from pipelines (See OVIRT-1745) > # It is not east to add tests for the code > It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the '{{scripts}}' directory. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070) ------------=_1510046714-26505-534 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1746?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren reassigned OVIRT-1746:</h3> <pre>Assignee: Barak Korren (was: infra)</pre> <blockquote><h3>Make stand-alone upstream source collection and updating tool</h3> <pre> Key: OVIRT-1746 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746 Project: oVirt - virtualization made easy Issue Type: New Feature Components: oVirt CI Reporter: Barak Korren Assignee: Barak Korren Labels: poll-upstream-sources, upstream-source-collector</pre> The upstream source collection code is currently built included in two different files – “{{upstream-source-collector.py}}” and “{{poll-upstream-sources.py}}”. The files reside in “{{jobs/confs/python-scripts}}” which in turn mean they are mean for embedding into jobs by JJB. This situation causes several issues: # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally # There is code duplication between the two python scripts # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example) # It is impossible to use the code from pipelines (See OVIRT-1745) # It is not east to add tests for the code It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the ‘{{scripts}}’ directory.</blockquote> — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070) <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYLyz…" 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> ------------=_1510046714-26505-534--

1 0

[JIRA] (OVIRT-1746) Make stand-alone upstream source collection and updating tool
by Barak Korren (oVirt JIRA) 07 Nov '17

07 Nov '17

Barak Korren created OVIRT-1746: ----------------------------------- Summary: Make stand-alone upstream source collection and updating tool Key: OVIRT-1746 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746 Project: oVirt - virtualization made easy Issue Type: New Feature Components: oVirt CI Reporter: Barak Korren Assignee: infra The upstream source collection code is currently built included in two different files - "{{upstream-source-collector.py}}" and "{{poll-upstream-sources.py}}". The files reside in "{{jobs/confs/python-scripts}}" which in turn mean they are mean for embedding into jobs by JJB. This situation causes several issues: # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally # There is code duplication between the two python scripts # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example) # It is impossible to use the code from pipelines (See OVIRT-1745) # It is not east to add tests for the code It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the '{{scripts}}' directory. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)

1 0

[JIRA] (OVIRT-1746) Make stand-alone upstream source collection and updating tool
by Barak Korren (oVirt JIRA) 07 Nov '17

07 Nov '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1746?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1746: -------------------------------- Epic Link: OVIRT-400 > Make stand-alone upstream source collection and updating tool > ------------------------------------------------------------- > > Key: OVIRT-1746 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, upstream-source-collector > > The upstream source collection code is currently built included in two different files - "{{upstream-source-collector.py}}" and "{{poll-upstream-sources.py}}". The files reside in "{{jobs/confs/python-scripts}}" which in turn mean they are mean for embedding into jobs by JJB. > This situation causes several issues: > # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally > # There is code duplication between the two python scripts > # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example) > # It is impossible to use the code from pipelines (See OVIRT-1745) > # It is not east to add tests for the code > It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the '{{scripts}}' directory. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)

1 0

[JIRA] (OVIRT-1680) Adapt STDCI pipelines for use in Gerrit projects
by Barak Korren (oVirt JIRA) 07 Nov '17

07 Nov '17

This is a multi-part message in MIME format... ------------=_1510045336-25494-507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1680?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1680: ------------------------------------- Adding OVIRT-1745 as a blocker because we need the upstream source collection code to support pipelines before we can migrate everything to pipelines. > Adapt STDCI pipelines for use in Gerrit projects > ------------------------------------------------ > > Key: OVIRT-1680 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1680 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: gerrit, standard-ci > > So far work on OVIRT-1522 focused on GitHub, and it is now feature-complete. > Now its time to make this work also available for Gerrit projects. > OVIRT-1629 is a blocker for this ticket because the '{{automation.yaml}}' implementation in the current STDCI pipelines does not yet support everything that the existing JJB YAML does. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070) ------------=_1510045336-25494-507 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1680?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren commented on OVIRT-1680:</h3> Adding OVIRT-1745 as a blocker because we need the upstream source collection code to support pipelines before we can migrate everything to pipelines. <blockquote><h3>Adapt STDCI pipelines for use in Gerrit projects</h3> <pre> Key: OVIRT-1680 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1680 Project: oVirt - virtualization made easy Issue Type: Improvement Components: oVirt CI Reporter: Barak Korren Assignee: infra Labels: gerrit, standard-ci</pre> So far work on OVIRT-1522 focused on GitHub, and it is now feature-complete. Now its time to make this work also available for Gerrit projects. OVIRT-1629 is a blocker for this ticket because the ‘{{automation.yaml}}’ implementation in the current STDCI pipelines does not yet support everything that the existing JJB YAML does.</blockquote> — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070) <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYLyz…" 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> ------------=_1510045336-25494-507--

1 0

[JIRA] (OVIRT-1745) Make upstream source collection and polling code usable for pipelines
by Barak Korren (oVirt JIRA) 07 Nov '17

07 Nov '17

This is a multi-part message in MIME format... ------------=_1510045269-22278-509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1745?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1745: -------------------------------- Epic Link: OVIRT-400 > Make upstream source collection and polling code usable for pipelines > --------------------------------------------------------------------- > > Key: OVIRT-1745 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1745 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, upstream-source-collector > > The upstream source collection and polling code is currently only suitable for use in Free-Style jobs. This is because: > # We support having 'jenkins' repositories (Where jobs expect STDCI code to be found) use the upstream sources mechanism to get the actual code from the main 'jenkins' repo in gerrit.ovirt.org > # This creates a situation where in order to get the STDCI code we need to run the upstream sources code > # This creates a chicken and and egg problem because the upstream sources code is part of the STDCI code > # To solve this issue we simply embedded the upstream sources code into the job code by using '{{#include}}' in JJB rather then running it as a stand-alone script. > # This technique is not usable for pipelines, so we need to come with a different solution and make the required adjustments to the source collection and polling code. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070) ------------=_1510045269-22278-509 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1745?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren updated OVIRT-1745:</h3> <pre>Epic Link: OVIRT-400</pre> <blockquote><h3>Make upstream source collection and polling code usable for pipelines</h3> <pre> Key: OVIRT-1745 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1745 Project: oVirt - virtualization made easy Issue Type: New Feature Components: oVirt CI Reporter: Barak Korren Assignee: infra Labels: poll-upstream-sources, upstream-source-collector</pre> The upstream source collection and polling code is currently only suitable for use in Free-Style jobs. This is because: # We support having ‘jenkins’ repositories (Where jobs expect STDCI code to be found) use the upstream sources mechanism to get the actual code from the main ‘jenkins’ repo in gerrit.ovirt.org # This creates a situation where in order to get the STDCI code we need to run the upstream sources code # This creates a chicken and and egg problem because the upstream sources code is part of the STDCI code # To solve this issue we simply embedded the upstream sources code into the job code by using ‘{{#include}}’ in JJB rather then running it as a stand-alone script. # This technique is not usable for pipelines, so we need to come with a different solution and make the required adjustments to the source collection and polling code.</blockquote> — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070) <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYLyz…" 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> ------------=_1510045269-22278-509--

1 0

[JIRA] (OVIRT-1745) Make upstream source collection and polling code usable for pipelines
by Barak Korren (oVirt JIRA) 07 Nov '17

07 Nov '17

Barak Korren created OVIRT-1745: ----------------------------------- Summary: Make upstream source collection and polling code usable for pipelines Key: OVIRT-1745 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1745 Project: oVirt - virtualization made easy Issue Type: New Feature Components: oVirt CI Reporter: Barak Korren Assignee: infra The upstream source collection and polling code is currently only suitable for use in Free-Style jobs. This is because: # We support having 'jenkins' repositories (Where jobs expect STDCI code to be found) use the upstream sources mechanism to get the actual code from the main 'jenkins' repo in gerrit.ovirt.org # This creates a situation where in order to get the STDCI code we need to run the upstream sources code # This creates a chicken and and egg problem because the upstream sources code is part of the STDCI code # To solve this issue we simply embedded the upstream sources code into the job code by using '{{#include}}' in JJB rather then running it as a stand-alone script. # This technique is not usable for pipelines, so we need to come with a different solution and make the required adjustments to the source collection and polling code. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)

1 0

[oVirt Jenkins] ovirt-appliance_ovirt-4.1-snapshot_build-artifacts-el7-x86_64 - Build # 330 - Failure!
by jenkins＠jenkins.phx.ovirt.org 07 Nov '17

07 Nov '17

------=_Part_38_1635750858.1509807911637 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.1-snapshot_build-artif… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.1-snapshot_build-artif… Build Number: 330 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #330 [Yuval Turgeman] automation: view install log in console ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_38_1635750858.1509807911637--

1 3

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #958
by jenkins＠jenkins.phx.ovirt.org 07 Nov '17

07 Nov '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-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-centos-updates-el7-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 2d0aecce46cfa1b3a1770ab846c983bf95f82328 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 2d0aecce46cfa1b3a1770ab846c983bf95f82328 Commit message: "Make mirror_mgr.sh drop yum MD cache before sync" > git rev-list 2d0aecce46cfa1b3a1770ab846c983bf95f82328 # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins3001790901476836819.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Error setting up repositories: centos-updates-el7: Check uncompressed DB failed Build step 'Execute shell' marked build as failure

1 4