On 01/27/2017 07:37 PM, James E. Blair wrote:
Clint Byrum <[email protected]> writes:
Excerpts from Oleksandr Karpenko's message of 2017-01-27 16:46:24 +0100:
Hello together,
Thanks for your answers.
Yes, we are interested in this feature and ready to contribute. But we
will need a support from your side for clear understanding how to
implement it.
My vision is a following:
Define a new configuration parameter for 'manager:
DependentPipelineManager', e.g. 'manager-policy: aggregate-gerrit-topics'.
When change set arrives DependentPipelineManager and topic is not empty,
consult gerrit server whether other change sets effecting pipeline
exists. And if it is a case, delay a pipeline until all change sets with
the same topic are ready to be proceeded.
That could work, for sure. However, with Zuul growing the ability to
push to Gerrit directly soon, it's unnecessarily Gerrit-dependent. We can
simply make Zuul do this with its own dependency specification methods.
That way topics and coordinated landings can stay de-coupled from
one-another.
Agreed. That should not be too difficult and should work with any Zuul
driver, not just Gerrit. The most difficult part of this work will be
altering the pipeline managers and data model to represent co-dependent
changes so that each co-dependent change is tested with all of the
others. Currently the queue is a DAG with exactly one item "ahead" of
another in the queue (but possibly multiple items behind), and each item
corresponding to a change. The data model would need to be altered to
account for changes being 'siblings' in some way. Perhaps that means
that an item should contain multiple changes (this sounds elegant). Or
non-live items representing each of the changes should be enqueued ahead
of real items representing the changes (this is probably easier but
sounds very awkward). Or perhaps the queue should no longer be a DAG
and should allow cycles (this sounds difficult).
-Jim
To me the first solution (one item contains multiple changes) also
sounds best from architecture point of view. Regarding the decision on
when to put several changes into one item I can imagine two ways:
- Allow cycles in the dependency DAG and merge cycles into a common
item. This would allow reuse of the dependency mechanism. But probably
cycle detection and handling could be very tricky in details. (e.g. what
changes should be merged into a single item if there are multiple
overlapping cycles in the DAG)
- Introduce a separate commit message tag (e.g. Merge-With) which will
directly merged into a common item. This could define a separate
'merge-with' graph where the complete graph would be merged into a
single item. This would be something separate but sounds easier and more
robust to be implemented at first glance.
Tobias
--
BMW Car IT GmbH
Tobias Henkel
Spezialist Entwicklung
Moosacher Straße 86
80809 München
Tel.: +49-89-189311-48
Fax: +49-89-189311-20
Mail: [email protected]
Web: http://www.bmw-carit.de
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Alexis Trolin
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
