<div dir="ltr">So for example, I don't see why changes at tripleo-quickstart can be reset if tripleo-ui fails, this is the kind of thing that maybe can be optimize.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 1:17 PM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora <<a href="mailto:ellorent@redhat.com" target="_blank">ellorent@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello there, <div><br></div><div>   After suffering a lot from zuul's tripleo gate piepeline queue reseting after failures on patches I have ask myself what would happend if we have more than one queue for gating tripleo.</div><div><br></div><div>   After a quick read here <a href="https://zuul-ci.org/docs/zuul/user/gating.html" target="_blank">https://zuul-ci.org/docs/zuul/user/gating.html</a>, I have found the following: </div><div><br></div><div>"<span style="background-color:rgb(238,238,238);color:rgb(62,67,73);font-family:Georgia,serif;font-size:17px">If changes with cross-project dependencies do not share a change queue then Zuul is unable to enqueue them together, and the first will be required to merge before the second is enqueued."</span> </div><div><br></div><div>   So it make sense to share zuul queue, but maybe only one queue for all tripleo projects is too  much, for example sharing queue between tripleo-ui and tripleo-quickstart, maybe we need for example to queues for product stuff and one for CI, so product does not get resetted if CI fails in a patch.</div><div><br></div><div>   What do you think ? <br></div></div></div></blockquote><div> </div></div><div>Probably a wrong example, as TripleO UI gate is using CI jobs running tripleo-quickstart scenarios.</div><div>We could create more queues for projects which are really independent from each other but we need to be very careful about it.<br></div><div>-- <br><div dir="ltr" class="m_-8163468395426657010gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Quique Llorente<div><br><div>Openstack TripleO CI</div></div></div></div></div></div>