Open Stack

On 10/11/18 8:53 AM, Felix Enrique Llorente Pastora wrote:
> 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.

Because if two incompatible changes are proposed to tripleo-quickstart 
and tripleo-ui and both end up in parallel gate queues at the same time, 
it's possible both queues could get wedged. Quickstart and the UI are 
not completely independent projects. Quickstart has roles for deploying 
the UI, which means there is a connection there.

I think the only way you could have independent gate queues is if you 
had two disjoint sets of projects that could be gated without any use of 
projects from the other set. I don't think it's possible to divide 
TripleO in that way, but if I'm wrong then maybe you could do multiple 
queues.

> 
> On Thu, Oct 11, 2018 at 1:17 PM Emilien Macchi <emilien at redhat.com 
> <mailto:emilien at redhat.com>> wrote:
> 
> 
> 
>     On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora
>     <ellorent at redhat.com <mailto:ellorent at redhat.com>> wrote:
> 
>         Hello there,
> 
>             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.
> 
>             After a quick read here
>         https://zuul-ci.org/docs/zuul/user/gating.html, I have found the
>         following:
> 
>         "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."
> 
>             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.
> 
>             What do you think ?
> 
>     Probably a wrong example, as TripleO UI gate is using CI jobs
>     running tripleo-quickstart scenarios.
>     We could create more queues for projects which are really
>     independent from each other but we need to be very careful about it.
>     -- 
>     Emilien Macchi
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Quique Llorente
> 
> Openstack TripleO CI
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>