- Infra - oVirt List Archives

[CQ]: 86978, 1 (cockpit-ovirt) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 01 Feb '18

01 Feb '18

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

1 0

[CQ]: 69668,7 (vdsm) failed "ovirt-master" system tests
by oVirt Jenkins 01 Feb '18

01 Feb '18

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

1 0

[CQ]: 86977, 1 (cockpit-ovirt) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 01 Feb '18

01 Feb '18

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

1 0

[JIRA] (OVIRT-1872) Jenkins outage 01.02.2018
by Evgheni Dereveanchin (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1872?page=com.atlassian.jira.… ] Evgheni Dereveanchin reassigned OVIRT-1872: ------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > Jenkins outage 01.02.2018 > ------------------------- > > Key: OVIRT-1872 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1872 > Project: oVirt - virtualization made easy > Issue Type: Outage > Reporter: Evgheni Dereveanchin > Assignee: Evgheni Dereveanchin > > Jenkins UI was slow and unreachable for several hours today. There were no major issues reported in the log yet CPU usage was very high. Jenkins was restarted to fix the issue, opening a ticket to investigate the cause and fix side effects if any -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1872) Jenkins outage 01.02.2018
by Evgheni Dereveanchin (oVirt JIRA) 01 Feb '18

01 Feb '18

This is a multi-part message in MIME format... ------------=_1517489276-29025-250 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Evgheni Dereveanchin created OVIRT-1872: ------------------------------------------- Summary: Jenkins outage 01.02.2018 Key: OVIRT-1872 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1872 Project: oVirt - virtualization made easy Issue Type: Outage Reporter: Evgheni Dereveanchin Assignee: infra Jenkins UI was slow and unreachable for several hours today. There were no major issues reported in the log yet CPU usage was very high. Jenkins was restarted to fix the issue, opening a ticket to investigate the cause and fix side effects if any -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078) ------------=_1517489276-29025-250 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Evgheni Dereveanchin created OVIRT-1872:</h3> <pre> Summary: Jenkins outage 01.02.2018 Key: OVIRT-1872 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1872 Project: oVirt - virtualization made easy Issue Type: Outage Reporter: Evgheni Dereveanchin Assignee: infra</pre> <p>Jenkins UI was slow and unreachable for several hours today. There were no major issues reported in the log yet CPU usage was very high. Jenkins was restarted to fix the issue, opening a ticket to investigate the cause and fix side effects if any</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)</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> ------------=_1517489276-29025-250--

1 0

[CQ]: 86968, 1 (ovirt-engine-wildfly) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 01 Feb '18

01 Feb '18

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

1 0

[CQ]: 86967, 1 (ovirt-hosted-engine-setup) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 01 Feb '18

01 Feb '18

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

1 0

[oVirt CI] standard-enqueue - Build #9474 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 01 Feb '18

01 Feb '18

------=_Part_451_1469550335.1517479434683 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/9474/ Build Name: #9474 Build Description: Gerrit: 82649 - ovirt-image-uploader (4.0, 4.1, 4.2, master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/82649 - title: automation: drop snapshot repos - project: ovirt-image-uploader - branch: ovirt-image-uploader-4.0 - author: Sandro Bonazzola <sbonazzo(a)redhat.com> ------=_Part_451_1469550335.1517479434683--

1 1

[JIRA] (OVIRT-1871) Wrong target milestone check on new 4.2 branches for ovirt-host-deploy
by sbonazzo (oVirt JIRA) 01 Feb '18

01 Feb '18

This is a multi-part message in MIME format... ------------=_1517478412-30235-139 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1871?page=com.atlassian.jira.… ] sbonazzo updated OVIRT-1871: ---------------------------- Epic Link: OVIRT-400 > Wrong target milestone check on new 4.2 branches for ovirt-host-deploy > ---------------------------------------------------------------------- > > Key: OVIRT-1871 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1871 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Gerrit/git > Reporter: sbonazzo > Assignee: infra > > I branched ovirt-host-deploy for 4.2 stabilization and on the new branch named ovirt-host-deploy-1.7 I get: > Check TM::#1539040::WARN, wrong target milestone: ovirt-4.2.1 (-1) https://gerrit.ovirt.org/#/c/86992/ > I'd like to configure the hook to match the branch with the ovirt-4.2* target milestones but couldn't find documentation on how to do that. > When fixing this, please also include link to how to do that, I've other projects that will need similar change. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078) ------------=_1517478412-30235-139 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1871?page=com.atlassian.jira.… ]</pre> <h3>sbonazzo updated OVIRT-1871:</h3> <pre>Epic Link: OVIRT-400</pre> <blockquote><h3>Wrong target milestone check on new 4.2 branches for ovirt-host-deploy</h3> <pre> Key: OVIRT-1871 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1871 Project: oVirt - virtualization made easy Issue Type: Bug Components: Gerrit/git Reporter: sbonazzo Assignee: infra</pre> <p>I branched ovirt-host-deploy for 4.2 stabilization and on the new branch named ovirt-host-deploy-1.7 I get: Check TM::#1539040::WARN, wrong target milestone: ovirt-4.2.1 (-1) <a href="https://gerrit.ovirt.org/#/c/86992/">https://gerrit.ovirt.org/#/c/86992/</a> I'd like to configure the hook to match the branch with the ovirt-4.2* target milestones but couldn't find documentation on how to do that. When fixing this, please also include link to how to do that, I've other projects that will need similar change.</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)</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> ------------=_1517478412-30235-139--

1 0

[JIRA] (OVIRT-1871) Wrong target milestone check on new 4.2 branches for ovirt-host-deploy
by sbonazzo (oVirt JIRA) 01 Feb '18

01 Feb '18

This is a multi-part message in MIME format... ------------=_1517478412-20389-117 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit sbonazzo created OVIRT-1871: ------------------------------- Summary: Wrong target milestone check on new 4.2 branches for ovirt-host-deploy Key: OVIRT-1871 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1871 Project: oVirt - virtualization made easy Issue Type: Bug Components: Gerrit/git Reporter: sbonazzo Assignee: infra I branched ovirt-host-deploy for 4.2 stabilization and on the new branch named ovirt-host-deploy-1.7 I get: Check TM::#1539040::WARN, wrong target milestone: ovirt-4.2.1 (-1) https://gerrit.ovirt.org/#/c/86992/ I'd like to configure the hook to match the branch with the ovirt-4.2* target milestones but couldn't find documentation on how to do that. When fixing this, please also include link to how to do that, I've other projects that will need similar change. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078) ------------=_1517478412-20389-117 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>sbonazzo created OVIRT-1871:</h3> <pre> Summary: Wrong target milestone check on new 4.2 branches for ovirt-host-deploy Key: OVIRT-1871 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1871 Project: oVirt - virtualization made easy Issue Type: Bug Components: Gerrit/git Reporter: sbonazzo Assignee: infra</pre> <p>I branched ovirt-host-deploy for 4.2 stabilization and on the new branch named ovirt-host-deploy-1.7 I get: Check TM::#1539040::WARN, wrong target milestone: ovirt-4.2.1 (-1) <a href="https://gerrit.ovirt.org/#/c/86992/">https://gerrit.ovirt.org/#/c/86992/</a> I'd like to configure the hook to match the branch with the ovirt-4.2* target milestones but couldn't find documentation on how to do that. When fixing this, please also include link to how to do that, I've other projects that will need similar change.</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)</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> ------------=_1517478412-20389-117--

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by Daniel Belenky (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] Daniel Belenky commented on OVIRT-1712: --------------------------------------- [~eedri] We'll probably add a cleanup function to global setup to ensure that lago can run smoothly. I'll talk with [~gbenhaim(a)redhat.com] offline to see what needs to be done. > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Barak Korren (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1870?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1870: -------------------------------- Epic Link: OVIRT-400 > kubevirt_kubevirt_standard-check-pr jobs often get stuck > -------------------------------------------------------- > > Key: OVIRT-1870 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects, Standard CI (Pipelines) > Reporter: Evgheni Dereveanchin > Assignee: infra > > kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console > The following message keeps repeating all the time: > 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' > 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:32 [check-patch.el7.x86_64] ++ wc -l > 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' > 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' > 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... > 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' > 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + wc -l > 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:56 [check-patch.el7.x86_64] 0 > 17:03:56 [check-patch.el7.x86_64] + sleep 10 > Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Barak Korren (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1870?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1870: ----------------------------------- Assignee: Barak Korren (was: infra) Component/s: Standard CI (Pipelines) CI client projects Epic Link: OVIRT-400 Issue Type: Outage (was: Bug) Priority: Highest (was: Medium) > kubevirt_kubevirt_standard-check-pr jobs often get stuck > -------------------------------------------------------- > > Key: OVIRT-1870 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: CI client projects, Standard CI (Pipelines) > Reporter: Evgheni Dereveanchin > Assignee: Barak Korren > Priority: Highest > > kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console > The following message keeps repeating all the time: > 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' > 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:32 [check-patch.el7.x86_64] ++ wc -l > 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' > 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' > 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... > 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' > 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + wc -l > 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:56 [check-patch.el7.x86_64] 0 > 17:03:56 [check-patch.el7.x86_64] + sleep 10 > Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

Evgheni Dereveanchin created OVIRT-1870: ------------------------------------------- Summary: kubevirt_kubevirt_standard-check-pr jobs often get stuck Key: OVIRT-1870 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Evgheni Dereveanchin Assignee: infra kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console The following message keeps repeating all the time: 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:32 [check-patch.el7.x86_64] ++ wc -l 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] + wc -l 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host 17:03:56 [check-patch.el7.x86_64] 0 17:03:56 [check-patch.el7.x86_64] + sleep 10 Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1229
by jenkins＠jenkins.phx.ovirt.org 31 Jan '18

31 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> Changes: [Dafna Ron] ovirt-host-deploy - dropping fc24 [Sandro Bonazzola] ovirt-host-deploy: re-align [Dafna Ron] ovirt-engine-wildfly - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly: re-align [Evgheni Dereveanchin] Update mirror snapshot for FC27 to fix gdbm [Dafna Ron] ovirt-engine-wildfly-overlay - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly-overlay: re-align [Gal Ben Haim] kubevirt-ansible: Update org [Sandro Bonazzola] ovirt-setup-lib: branched for 4.3 development [Sandro Bonazzola] ovirt-guest-agent: re-align [Nir Soffer] ioprocess: Add project for 4.2 [Martin Sivak] Cleanup and prepare SLA packages for 4.2 ------------------------------------------ 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 1b9164a35a85fde7ff0218fa6cacfed04472e381 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 1b9164a35a85fde7ff0218fa6cacfed04472e381 Commit message: "Cleanup and prepare SLA packages for 4.2" > git rev-list 7884783969141c572c6a8fd1331a612ecfa542ac # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins5771763202377004232.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 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/gen error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7/gen' Build step 'Execute shell' marked build as failure

1 1

oVirt infra weekly meeting notes 31.01.2018
by Evgheni Dereveanchin 31 Jan '18

31 Jan '18

Hi everyone, Please find the topics of this week's infra meeting below: PHX DC - Core network equipment change completed on Monday - Repo definitions removed from puppet as part of OVIRT-1810 <https://ovirt-jira.atlassian.net/browse/OVIRT-1810> - New Fedora 27 snapshot enabled to fix GDBM issue OVIRT-1839 <https://ovirt-jira.atlassian.net/browse/OVIRT-1839> - Issue with lago port taken on slaves showing up again OVIRT-1712 <https://ovirt-jira.atlassian.net/browse/OVIRT-1712> - Disk filling on templates.ovirt.org OVIRT-1869 <https://ovirt-jira.atlassian.net/browse/OVIRT-1869> - Kubevirt jobs take up slaves -> open ticket - Jenkins update tested on Staging OVIRT-1858 <https://ovirt-jira.atlassian.net/browse/OVIRT-1858> AI - Import CoreOS to glance -- Regards, Evgheni Dereveanchin

1 0

[CQ]: 83154,4 (ovirt-engine-wildfly) failed "ovirt-4.2" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 83154,4 (ovirt-engine-wildfly) is probably the reason behind recent system test failures in the "ovirt-4.2" 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/83154/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/385/

1 0

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

This is a multi-part message in MIME format... ------------=_1517412734-27111-145 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] eyal edri moved OVIRT-1788 to OST-99: ------------------------------------- Component/s: (was: OST) Project: oVirt system tests (was: oVirt - virtualization made easy) Workflow: Software Simplified Workflow for Project OST (was: Task Management Workflow) Key: OST-99 (was: OVIRT-1788) > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > 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#100077) ------------=_1517412734-27111-145 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ]</pre> <h3>eyal edri moved OVIRT-1788 to OST-99:</h3> <pre> Component/s: (was: OST) Project: oVirt system tests (was: oVirt - virtualization made easy) Workflow: Software Simplified Workflow for Project OST (was: Task Management Workflow) Key: OST-99 (was: OVIRT-1788)</pre> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OST-99 URL: https://ovirt-jira.atlassian.net/browse/OST-99 Project: oVirt system tests Issue Type: Improvement 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#100077)</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> ------------=_1517412734-27111-145--

1 0

[CQ]: 86940, 3 (ovirt-setup-lib) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

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

1 0

[CQ]: 86944,1 (ioprocess) failed "ovirt-master" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 86944,1 (ioprocess) 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/86944/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5175/

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1712: ---------------------------------- So what is the alternate fix? > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by Daniel Belenky (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] Daniel Belenky commented on OVIRT-1712: --------------------------------------- We've abandoned the fix from mock_runner's side for now > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

This is a multi-part message in MIME format... ------------=_1517408202-32693-199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1712: ---------------------------------- [~dbelenky@redhat.com][~gbenhaim@redhat.com] what was the latest fix on this issue? did we abandon the fix on mock runner ? is there a plan to fix it from lago side? > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517408202-32693-199 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ]</pre> <h3>eyal edri commented on OVIRT-1712:</h3> <p>[~dbelenky@redhat.com][~gbenhaim@redhat.com] what was the latest fix on this issue? did we abandon the fix on mock runner ? is there a plan to fix it from lago side?</p> <blockquote><h3>OST jobs fails on “address already in use”</h3> <pre> Key: OVIRT-1712 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: eyal edri Assignee: Gal Ben Haim Priority: High</pre> <p>Evgheni, Was there any change recently to Lago slaves? On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < piotr.kliczewski(a)gmail.com> wrote:</p> <blockquote><p>I attempted to run manual OST twice and both failed with below issue. Can someone take a look?</p> <p>Thanks, Piotr</p> <p>2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: :DEBUG::</p> <pre>File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636,</pre> <p>in wrapper</p> <pre> return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line</pre> <p>111, in wrapper</p> <pre> with utils.repo_server_context(args[0]): File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line</pre> <p>100, in repo_server_context</p> <pre> root_dir=prefix.paths.internal_repo(), File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76,</pre> <p>in _create_http_server</p> <pre> generate_request_handler(root_dir), File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ self.server_bind() File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind self.socket.bind(self.server_address) File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args)</pre> <p>2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error occured, aborting Traceback (most recent call last):</p> <pre>File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in</pre> <p>do_run</p> <pre> self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line</pre> <p>184, in do_run</p> <pre> self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in</pre> <p>wrapper</p> <pre> return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in</pre> <p>wrapper</p> <pre> return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166,</pre> <p>in do_deploy</p> <pre> prefix.deploy() File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636,</pre> <p>in wrapper</p> <pre> return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line</pre> <p>111, in wrapper</p> <pre> with utils.repo_server_context(args[0]): File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line</pre> <p>100, in repo_server_context</p> <pre> root_dir=prefix.paths.internal_repo(), File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76,</pre> <p>in _create_http_server</p> <pre> generate_request_handler(root_dir), File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ self.server_bind() File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind self.socket.bind(self.server_address) File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args)</pre> <p>error: [Errno 98] Address already in use <em>____________________________________________</em>_ Infra mailing list Infra(a)ovirt.org <a href="http://lists.ovirt.org/mailman/listinfo/infra">http://lists.ovirt.org/mailman/listinfo/infra</a></p></blockquote> <p>— Eyal edri MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</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> ------------=_1517408202-32693-199--

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by Dafna Ron (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] Dafna Ron commented on OVIRT-1712: ---------------------------------- We had 2 failures today on network in use. in the latest one I can see that the build that ran before failed on libvirt issue. Here is the failed build: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5173/ Here is the build that failed before: http://jenkins.ovirt.org/computer/ovirt-srv17.phx.ovirt.org/builds This is the host: http://jenkins.ovirt.org/computer/ovirt-srv17.phx.ovirt.org/ > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1869) add new disk to templates.ovirt.org
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1869?page=com.atlassian.jira.… ] Evgheni Dereveanchin reassigned OVIRT-1869: ------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > add new disk to templates.ovirt.org > ----------------------------------- > > Key: OVIRT-1869 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1869 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: Evgheni Dereveanchin > > We need to mount /var/www/html/bundles as a separate filesystem, same as we do for /var/www/html/repo on the templates file server. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1869) add new disk to templates.ovirt.org
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

Evgheni Dereveanchin created OVIRT-1869: ------------------------------------------- Summary: add new disk to templates.ovirt.org Key: OVIRT-1869 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1869 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Evgheni Dereveanchin Assignee: infra We need to mount /var/www/html/bundles as a separate filesystem, same as we do for /var/www/html/repo on the templates file server. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86912,2 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 86912,2 (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/86912/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5173/

1 0

[CQ]: 86859, 3 (ovirt-engine-api-model) failed "ovirt-master" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 86859,3 (ovirt-engine-api-model) 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/86859/3 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5170/

1 0

[CQ]: 85206,1 (ovirt-iso-uploader) failed "ovirt-4.2" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 85206,1 (ovirt-iso-uploader) is probably the reason behind recent system test failures in the "ovirt-4.2" 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/85206/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/380/

1 0

[CQ]: 86951, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

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

1 0

[CQ]: 86950, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

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

1 0

[oVirt Jenkins] ovirt-system-tests_he-basic-ansible-suite-master - Build # 20 - Failure!
by jenkins＠jenkins.phx.ovirt.org 31 Jan '18

31 Jan '18

------=_Part_420_2006938412.1517279453385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-mast… Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-mast… Build Number: 20 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #20 [Roy Golan] perf-suite: log rotate more frequently [Barak Korren] Make standard-enqueue support non-ovirt queues [Barak Korren] Allow customizing CQ mail addresses [Barak Korren] Enable customizing the server we deploy tested to [Barak Korren] Make pipeline-loader support upstream sources [Barak Korren] Made clone url for 'jenkins' customizable ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_420_2006938412.1517279453385--

1 1

[CQ]: 86939, 3 (ovirt-setup-lib) failed "ovirt-4.1" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

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

1 0

[CQ]: 86939, 3 (ovirt-setup-lib) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

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

1 0

[CQ]: 86938,2 (ovirt-setup-lib) failed "ovirt-4.1" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86938,2 (ovirt-setup-lib) is probably the reason behind recent system test failures in the "ovirt-4.1" 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/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1552/

1 0

[CQ]: 86938,2 (ovirt-setup-lib) failed "ovirt-4.2" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86938,2 (ovirt-setup-lib) is probably the reason behind recent system test failures in the "ovirt-4.2" 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/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/374/

1 0

[CQ]: 86913,2 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86913,2 (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/86913/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5164/

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1867: ------------------------------------- [~rmohr(a)redhat.com] the main issue I have with the concept you suggest is that it chains the code to a specific instance of the CI system. The point of STDCI is to be a standard - you can take a compliant project and build/test it the same way on different CI systems. They way you suggest to handle secrets - it essentially chains the project to a specific CI system instance - the one that knows the right private key. This concept makes perfect sense for PAAS providers like Travis that want to lock you into the single instance their platform... Our view of credentials is also slightly different - instead of a developer providing his own credentials for using service X, he just asks for access for service X, and it becomes the CI system's responsibility to figure out how to provide access to that service. Having said the above, implementing what you ask for is not difficult, so we may add this soon as an additional feature for our existing credentials support. The main challenge would be to find where to store all the private keys and provide access to the public keys. Our system doesn't really have a UI that is not linked to a specific build/test run, since so far the assumption has always been that all communication with the CI system is done via commits or comments to the SCM. > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1224
by jenkins＠jenkins.phx.ovirt.org 30 Jan '18

30 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> Changes: [Sandro Bonazzola] copy-create-job: drop EOLed Fedoras [Dafna Ron] otopi - dropping fc24 [Dafna Ron] ovirt-hosted-engine-setup - dropping fc24 [Daniel Belenky] Mock runner to search full script path [Sandro Bonazzola] otopi: 4.2 and latest fedora [Sandro Bonazzola] ovirt-hosted-engine-setup: 4.2 and new Fedoras [Sandro Bonazzola] ovirt-live: drop project ------------------------------------------ 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 453d3f78c51516ce19b686b9ac141d2ced2260d7 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 453d3f78c51516ce19b686b9ac141d2ced2260d7 Commit message: "ovirt-live: drop project" > git rev-list ffe020fb18b7f872bc817ba9eec0c0d5a82bc489 # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins4363023534009612747.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 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

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517318718-26640-235 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1867: -------------------------------- Epic Link: OVIRT-400 Issue Type: New Feature (was: By-EMAIL) > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517318718-26640-235 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren updated OVIRT-1867:</h3> <pre> Epic Link: OVIRT-400 Issue Type: New Feature (was: By-EMAIL)</pre> <blockquote><h3>Allow embedded secrets inside the source repo for CI</h3> <pre> Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</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> ------------=_1517318718-26640-235--

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1867: -------------------------------- Epic Link: OVIRT-400 > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Component/s: Standard CI (Pipelines) > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines) > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Epic Link: OVIRT-400 > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Epic Link: OVIRT-400 > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Issue Type: New Feature (was: By-EMAIL) > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1868: ------------------------------------- {quote} Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. {quote} We use pipelines - Jenkinfiles are pipeline-based but also impose a very specific workflow, while generic pipelines are far more flexible. {quote} With the Jenkinsfile the chroot based approach seems to be pretty obsolete, {quote} Nope,there are quite a few things the current approach makes easy to do that Jenkinsfile would make complex or impossible. The main point of the current approach is not the use of mock/chroot, which is an implementation detail, but the use of a standardized generic configuration format, where different backends could be implemented. It allows the CI team to deal effectively with how CI resources are distributed and managed while allowing developers to just specify what they need. With Jenkinsfile the developers would have to deal with a lot of the mechanics or resource allocation and management, while the CI team will be unable to control how resources are used or to ensure they are returned to usable state when jobs finish. The configuration formal also allows the CI system to gain a good knowledge about the dependencies for a given test/build process. This allows it to to control how and which versions of these dependencies are provided. (For example, when you ask for yum repositories, the CI system ensure you get the same view of these repositories from the point in time in which the jobs started, even if they get updated while the job is running). Jenkinsfile, as it stands, will also chain us to a very specific CI orchestration engine. Don't get me wrong, Jenkins is nice, but its good to know we can switch the backend and have that switch be mostly transparent to project developers. Its also very convenient to have a client-side mini-backend, it would be quite impossible to make such a backend for a Jenkinsfile. {quote} if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. {quote} STDCI have been quite valuable so far TYVM. Using the docker agent as you suggest will actually make it lees so because it will chain you to a very specific method of resource allocation. It will make it harder to do things like ensure a certain test script gets its own bare-metal machine to run on. Docker containers are useful - but many people couldn't care less, they just know they need to target 'el7' and need a few dependencies for that, forcing then to then deal with finding or making a suitable container image will just divert efforts from the more important work of writing the actual code to be tested. The main thing that Jenkinsfiles have to offer that STDCI does not support currently is the ability to sequentially chain multiple steps together and have control flow to decide which steps get executed. We are going to make STDCI provide that, and we're going to try to do that in a syntax that would be familiar to anyone who is familiar with Jenkinsfiles. But it is going to be a subset of the Jenkinsfie syntax. Things like node() for example, are probably not going to be supported since STDCI already provides higher-level ways of requesting node allocation. > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86903, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

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

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Roman Mohr (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Roman Mohr commented on OVIRT-1867: ----------------------------------- In my opinion, having the secrets encrypted in the code is better, since you don't need accounts for engineers on CI to do that. A public rsa key can be made accessible for the whole world. With other words, the issue is exactly about the self-service and not about how to bind existing secrets. It is also related to OVIRT-1868. In combination with a Jenkinsfile, pretty much the whole yaml/script/chroot can be made obsolete, however that is a different story. > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86869, 1 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

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

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Daniel Belenky (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517312708-12381-241 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1867: ---------------------------------- Component/s: STDCI DSL Standard CI (Pipelines) > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517312708-12381-241 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ]</pre> <h3>Daniel Belenky updated OVIRT-1867:</h3> <pre> Component/s: STDCI DSL Standard CI (Pipelines)</pre> <blockquote><h3>Allow embedded secrets inside the source repo for CI</h3> <pre> Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</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> ------------=_1517312708-12381-241--

1 0