Open Stack

So if I'm understanding you correctly, a job can fail and will be held onto
in case one of the parent jobs causes a reset in which case it will be
retested?


On Thu, Jun 5, 2014 at 11:24 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2014-06-05 19:50:30 -0700 (-0700), Kevin Benton wrote:
> [...]
> > At a queue size of 20 and an 80% success rate. The patch in
> > position 20 only has a ~44% chance of getting merged. However,
> > with a queue size of 4, the patch in position 4 has a ~71% chance
> > of getting merged.
> [...]
>
> Your theory misses an important detail. A change is not ejected from
> a dependent Zuul queue like that of the gate pipeline simply for
> failing a voting job. It only gets ejected IF all the changes ahead
> of it on which it's being tested also pass all their jobs (or if
> it's at the head of the queue). This makes the length of the queue
> irrelevant to the likelihood of a change eventually making it
> through on its own, and only a factor on the quantity of resources
> and time we spend testing it.
>
> The reason we implemented dynamic queue windowing was to help
> conserve the donated resources we use at times when there are a lot
> of changes being gated and failure rates climb (without this measure
> we were entering something akin to virtual memory swap paging
> hysteresis patterns, but with virtual machine quotas in providers
> instead of virtual memory).
> --
> Jeremy Stanley
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/263bbc7f/attachment.html>