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 <emil...@redhat.com <mailto:emil...@redhat.com>> wrote:On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora <ellor...@redhat.com <mailto:ellor...@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-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
