Open Stack

On 01/27/2017 07:37 PM, James E. Blair wrote:
> Clint Byrum <clint at fewbar.com> 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: tobias.henkel at bmw.de
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
-------------------------------------------------------------------------