January 2018 - Infra - oVirt List Archives

[CQ]: 86138, 6 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86138,6 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 86114,4 (vdsm) 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 86114,4 (vdsm) 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/86138/6 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86114/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4967/

1 0

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

18 Jan '18

------=_Part_145_390858701.1516245236093 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/175/ Build Number: 175 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #175 [Yedidyah Bar David] Revert "upgrade_suites: Update ovirt-engine-metrics" [Gal Ben Haim] ost: Fix Lago custom repo [Greg Sheremeta] ovirt-js-dependencies: add jobs for fc27, add 4.2 branch ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_145_390858701.1516245236093--

1 1

[JIRA] (OVIRT-1853) gerrit hook adds patch to bug mentioned not in Bug-Url
by eyal edri (oVirt JIRA) 18 Jan '18

18 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1853?page=com.atlassian.jira.… ] eyal edri reassigned OVIRT-1853: -------------------------------- Assignee: Anton Marchukov (was: infra) > gerrit hook adds patch to bug mentioned not in Bug-Url > ------------------------------------------------------ > > Key: OVIRT-1853 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1853 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: Anton Marchukov > > Hi, > I pushed [1], with a link to [2], and it was added there, even though > the link was not in 'Bug-Url:'. > [1] https://gerrit.ovirt.org/86530 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1535904 > -- > Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1853) gerrit hook adds patch to bug mentioned not in Bug-Url
by Yedidyah Bar David (oVirt JIRA) 18 Jan '18

18 Jan '18

Yedidyah Bar David created OVIRT-1853: ----------------------------------------- Summary: gerrit hook adds patch to bug mentioned not in Bug-Url Key: OVIRT-1853 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1853 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra Hi, I pushed [1], with a link to [2], and it was added there, even though the link was not in 'Bug-Url:'. [1] https://gerrit.ovirt.org/86530 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1535904 -- Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[oVirt Jenkins] ovirt-node-ng_master_build-artifacts-el7-x86_64 - Build # 670 - Failure!
by jenkins＠jenkins.phx.ovirt.org 18 Jan '18

18 Jan '18

------=_Part_154_1136662867.1516272380235 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6… Build: http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6… Build Number: 670 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #670 [Yuval Turgeman] scripts: timeout when waiting for vm to install ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_154_1136662867.1516272380235--

1 1

[CQ]: 86131, 7 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86131,7 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 86114,4 (vdsm) 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 86114,4 (vdsm) 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/86131/7 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86114/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4959/

1 0

[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1852: ----------------------------------- Assignee: Barak Korren (was: infra) > Make change-queue handle continues steaks of failed patches together > -------------------------------------------------------------------- > > Key: OVIRT-1852 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: Barak Korren > > Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right): > a1 a2 a3 a4 b1 a5 > Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'. > When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): > a1 a2 a3 > a1 <- a1 will be removed from the queue following this > a2 a3 a4 b1 a5 > a2 a3 > a2 <- a2 will be removed from the queue following this > a3 a4 b1 a5 > a3 a4 > a3 <- a3 will be removed from the queue following this > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. > We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. > With the starting conditions as described above, the sets of changes being tested would be: > a1 a2 a3 a4 b1 a5 > a1 a2 a3 <- We are starting a normal bisection here because at this point there is > not yet any knowledge about the failures in 'a' > a1 <- a1 will be removed and the failure in 'a' will be recorded > a2 a3 a4 b1 a5 > a2 <- Now the mechanism described above kicks in and a3 is tested alone > and removed > a3 a4 b1 a5 > a3 <- Same mechanism now causes a2 to be tested alone > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

Barak Korren created OVIRT-1852: ----------------------------------- Summary: Make change-queue handle continues steaks of failed patches together Key: OVIRT-1852 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: infra Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right): a1 a2 a3 a4 b1 a5 Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'. When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): a1 a2 a3 a1 <- a1 will be removed from the queue following this a2 a3 a4 b1 a5 a2 a3 a2 <- a2 will be removed from the queue following this a3 a4 b1 a5 a3 a4 a3 <- a3 will be removed from the queue following this a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. With the starting conditions as described above, the sets of changes being tested would be: a1 a2 a3 a4 b1 a5 a1 a2 a3 <- We are starting a normal bisection here because at this point there is not yet any knowledge about the failures in 'a' a1 <- a1 will be removed and the failure in 'a' will be recorded a2 a3 a4 b1 a5 a2 <- Now the mechanism described above kicks in and a3 is tested alone and removed a3 a4 b1 a5 a3 <- Same mechanism now causes a2 to be tested alone a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516276894-19060-322 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1852: -------------------------------- Epic Link: OVIRT-400 > Make change-queue handle continues steaks of failed patches together > -------------------------------------------------------------------- > > Key: OVIRT-1852 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right): > a1 a2 a3 a4 b1 a5 > Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'. > When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): > a1 a2 a3 > a1 <- a1 will be removed from the queue following this > a2 a3 a4 b1 a5 > a2 a3 > a2 <- a2 will be removed from the queue following this > a3 a4 b1 a5 > a3 a4 > a3 <- a3 will be removed from the queue following this > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. > We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. > With the starting conditions as described above, the sets of changes being tested would be: > a1 a2 a3 a4 b1 a5 > a1 a2 a3 <- We are starting a normal bisection here because at this point there is > not yet any knowledge about the failures in 'a' > a1 <- a1 will be removed and the failure in 'a' will be recorded > a2 a3 a4 b1 a5 > a2 <- Now the mechanism described above kicks in and a3 is tested alone > and removed > a3 a4 b1 a5 > a3 <- Same mechanism now causes a2 to be tested alone > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516276894-19060-322 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren updated OVIRT-1852:</h3> <pre>Epic Link: OVIRT-400</pre> <blockquote><h3>Make change-queue handle continues steaks of failed patches together</h3> <pre> Key: OVIRT-1852 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: infra</pre> <p>Lets assume we have a change queue testing projects ‘a’ and ‘b’ where patches had been submitted in the following order (from left to right): a1 a2 a3 a4 b1 a5 Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project ‘a’. When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): a1 a2 a3 a1 <- a1 will be removed from the queue following this a2 a3 a4 b1 a5 a2 a3 a2 <- a2 will be removed from the queue following this a3 a4 b1 a5 a3 a4 a3 <- a3 will be removed from the queue following this a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of ‘a’ go the ‘tested’. As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. With the starting conditions as described above, the sets of changes being tested would be: a1 a2 a3 a4 b1 a5 a1 a2 a3 <- We are starting a normal bisection here because at this point there is</p> <pre>not yet any knowledge about the failures in 'a'</pre> <p>a1 <- a1 will be removed and the failure in ‘a’ will be recorded a2 a3 a4 b1 a5 a2 <- Now the mechanism described above kicks in and a3 is tested alone</p> <pre>and removed</pre> <p>a3 a4 b1 a5 a3 <- Same mechanism now causes a2 to be tested alone a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of ‘a’ go the ‘tested’. So a total of 12 test runs – we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have.</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</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> ------------=_1516276894-19060-322--

1 0

[JIRA] (OVIRT-1851) Make chaneg-queue throw-away not-building patches quickly
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516275027-10230-333 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1851?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1851: ----------------------------------- Assignee: Barak Korren (was: infra) > Make chaneg-queue throw-away not-building patches quickly > --------------------------------------------------------- > > Key: OVIRT-1851 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: Barak Korren > > Currently test failures and build failures are treated the same by the check queue - in both cases the change queue runs a bisection to find out the change that caused the failure. > It the case of a build failure - it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516275027-10230-333 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1851?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren reassigned OVIRT-1851:</h3> <pre>Assignee: Barak Korren (was: infra)</pre> <blockquote><h3>Make chaneg-queue throw-away not-building patches quickly</h3> <pre> Key: OVIRT-1851 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: Barak Korren</pre> <p>Currently test failures and build failures are treated the same by the check queue – in both cases the change queue runs a bisection to find out the change that caused the failure. It the case of a build failure – it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs.</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</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> ------------=_1516275027-10230-333--

1 0