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