- Infra - oVirt List Archives

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by eyal edri (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1918: ---------------------------------- Maybe we need to use always the official release repo as fallback to tested? In case a specific PKG failed to build and it's maintainer didn't make sure to fix it and redeploy, it makes sense to get missing pkgs from latest official release, as we do in OST. Once the maintainer of the project will build a new image and it passes, it will be in tested. On Mar 6, 2018 14:02, "sbonazzo (oVirt JIRA)" <jira(a)ovirt-jira.atlassian.net> wrote: [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] sbonazzo commented on OVIRT-1918: I'm not sure that the bisection really works then, since we have still packages released 2 months ago not yet landing on tested. I don't recall to have seen any job triggered automatically after a change-queue-tester failure doing bisection tests. Single project tests in change-queue-tester Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on t ested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA < https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. < https://redhat.com/trusted> — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081) > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

Re: [JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Eyal Edri 06 Mar '18

06 Mar '18

Maybe we need to use always the official release repo as fallback to tested? In case a specific PKG failed to build and it's maintainer didn't make sure to fix it and redeploy, it makes sense to get missing pkgs from latest official release, as we do in OST. Once the maintainer of the project will build a new image and it passes, it will be in tested. On Mar 6, 2018 14:02, "sbonazzo (oVirt JIRA)" <jira(a)ovirt-jira.atlassian.net> wrote: [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] sbonazzo commented on OVIRT-1918: I'm not sure that the bisection really works then, since we have still packages released 2 months ago not yet landing on tested. I don't recall to have seen any job triggered automatically after a change-queue-tester failure doing bisection tests. Single project tests in change-queue-tester Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on t ested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA < https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. < https://redhat.com/trusted> — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081) _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by sbonazzo (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] sbonazzo commented on OVIRT-1918: --------------------------------- I'm not sure that the bisection really works then, since we have still packages released 2 months ago not yet landing on tested. I don't recall to have seen any job triggered automatically after a change-queue-tester failure doing bisection tests. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

[CQ]: 88250,4 (ovirt-engine-metrics) failed "ovirt-4.2" system tests
by oVirt Jenkins 06 Mar '18

06 Mar '18

Change 88250,4 (ovirt-engine-metrics) 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/88250/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1041/

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA) 06 Mar '18

06 Mar '18

This is a multi-part message in MIME format... ------------=_1520333776-20649-136 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:56 AM: -------------------------------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This is the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081) ------------=_1520333776-20649-136 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:56 AM:</h3> <p>{quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This is the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p> <p>was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p> <blockquote><h3>Single project tests in change-queue-tester</h3> <pre> Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra</pre> <p>Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG 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>></p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</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> ------------=_1520333776-20649-136--

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA) 06 Mar '18

06 Mar '18

This is a multi-part message in MIME format... ------------=_1520333757-27720-121 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM: -------------------------------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081) ------------=_1520333757-27720-121 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM:</h3> <p>{quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p> <p>was (Author: bkorren(a)redhat.com) {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p> <p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p> <p>[~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX.</p> <blockquote><h3>Single project tests in change-queue-tester</h3> <pre> Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra</pre> <p>Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG 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>></p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</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> ------------=_1520333757-27720-121--

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1918: ------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by sbonazzo (oVirt JIRA) 06 Mar '18

06 Mar '18

sbonazzo created OVIRT-1918: ------------------------------- Summary: Single project tests in change-queue-tester Key: OVIRT-1918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again "ci re-merge please" again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #1262
by jenkins＠jenkins.phx.ovirt.org 06 Mar '18

06 Mar '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/1262/displ…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision ea02d358e4b5ba495ce4f865f48d932427cd0bdb (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f ea02d358e4b5ba495ce4f865f48d932427cd0bdb Commit message: "Revert "Install base packeges and start services from global_setup"" > git rev-list --no-walk ea02d358e4b5ba495ce4f865f48d932427cd0bdb # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins562107027827444518.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror epel-el6 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1474, in _commonLoadRepoXML if self._latestRepoXML(local): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1443, in _latestRepoXML oxml = self._saveOldRepoXML(local) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1300, in _saveOldRepoXML shutil.copy2(local, old_local) File "/usr/lib64/python2.7/shutil.py", line 131, in copy2 copystat(src, dst) File "/usr/lib64/python2.7/shutil.py", line 98, in copystat os.utime(dst, (st.st_atime, st.st_mtime)) OSError: [Errno 2] No such file or directory: '/home/jenkins/mirrors_cache/centos-extras-el7/repomd.xml.old.tmp' Build step 'Execute shell' marked build as failure

1 1

[JIRA] (OVIRT-1917) Off by one bug in nested config parser
by Daniel Belenky (oVirt JIRA) 06 Mar '18

06 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1917?page=com.atlassian.jira.… ] Daniel Belenky reassigned OVIRT-1917: ------------------------------------- Assignee: Daniel Belenky (was: infra) > Off by one bug in nested config parser > -------------------------------------- > > Key: OVIRT-1917 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1917 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: Daniel Belenky > Priority: Highest > > There is an off by one bug in _cartesian_multiplication() (nested_config.py) where if given a list of vectors to try and merge with each other, the last vector, if merged, needs to be excluded from the final result since it was already merged. In other cases, if the last vector was not merged, it needs to be included in the final result. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)

1 0