[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together

Thursday, 18 January 2018

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.jir...
]

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.jir...
]</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 &lsquo;a&rsquo; and
&lsquo;b&rsquo; 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
&lsquo;a&rsquo;. 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 &lt;- a1 will be removed from the queue following this a2 a3 a4 b1
a5 a2 a3 a2 &lt;- a2 will be removed from the queue following this a3 a4 b1 a5 a3 a4
a3 &lt;- a3 will be removed from the queue following this a4 b1 a5 a4 &lt;- a4
will be removed from the queue following this b1 a5 b1 &lt;- b1 will be removed from
the queue following this a5 &lt;- This run will finally succeed letting the build of
&lsquo;a&rsquo; go the &lsquo;tested&rsquo;. 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
&lt;- 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 &lt;- a1 will be removed and the failure in &lsquo;a&rsquo; will
be recorded a2 a3 a4 b1 a5 a2 &lt;- Now the mechanism described above kicks in and a3
is tested alone</p>
<pre>and removed</pre>
<p>a3 a4 b1 a5 a3 &lt;- Same mechanism now causes a2 to be tested alone a4 b1 a5
a4 &lt;- a4 will be removed from the queue following this b1 a5 b1 &lt;- b1 will
be removed from the queue following this a5 &lt;- This run will finally succeed
letting the build of &lsquo;a&rsquo; go the &lsquo;tested&rsquo;. So a
total of 12 test runs &ndash; 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>&mdash; This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100076)</p>

------------=_1516276894-19060-322--

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011