<div dir="ltr">++  \m/</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 26, 2013 at 10:10 AM, James E. Blair <span dir="ltr"><<a href="mailto:jeblair@openstack.org" target="_blank">jeblair@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We recently made a change to Zuul's scheduling algorithm (how it<br>
determines which changes to combine together and run tests).  Now when a<br>
change fails tests (or has a merge conflict), Zuul will move it out of<br>
the series of changes that it is stacking together to be tested, but it<br>
will still keep that change's position in the queue.  Jobs for changes<br>
behind it will be restarted without the failed change in their proposed<br>
repo states.  And if something later fails ahead of it, Zuul will once<br>
again put it back into the stream of changes it's testing and give it<br>
another chance.<br>
<br>
To visualize this, we've updated the status screen to include a tree<br>
view:<br>
<br>
  <a href="http://status.openstack.org/zuul/" target="_blank">http://status.openstack.org/zuul/</a><br>
<br>
(If you already have that loaded, be sure to hit reload.)<br>
<br>
In Zuul, this is called the Nearest Non-Failing Item (NNFI) algorithm<br>
because in short, each item in a queue is at all times being tested<br>
based on the nearest non-failing item ahead of it in the queue.<br>
<br>
On the infrastructure side, this is going to drive our use of cloud<br>
resources even more, as Zuul will now try to run as many jobs as it can,<br>
continuously.  Every time a change fails, all of the jobs for changes<br>
behind it will be aborted and restarted with a new proposed future<br>
state.<br>
<br>
For developers, this means that changes should land faster, and more<br>
throughput overall, as Zuul won't be waiting as long to re-test changes<br>
after a job has failed.  And that's what this is ultimately about --<br>
virtual machines are cheap compared to developer time, so the more<br>
velocity our automated tests can sustain, the more velocity our project<br>
can achieve.<br>
<br>
-Jim<br>
<br>
<br>
(PS: There is a known problem with the status page not being able to<br>
display the tree correctly while Zuul is in the middle of recalculating<br>
the change graph.  That should be fixed by next week, but in the mean<br>
time, just enjoy the show.)<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>