Open Stack

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