Open Stack

On 2017-01-18 16:34:56 -0500 (-0500), Doug Hellmann wrote:
> When I tried to merge the upper-constraints updates for the library
> releases we did today, I ran into quite a lot of merge conflicts
> with the Oslo libraries. I'm exploring options for reducing the
> likelihood that those sorts of conflicts will occur with a few
> patches that change how we generate the constraints list.
[...original options omitted...]

Have you considered following a similar pattern to requirements
updates? Namely, have the job check Gerrit to find out if a
constraints update change is already open. If not, create one like
now. If so, retrieve the last patchset, amend it with the desired
edit, and then push it back into Gerrit.

This approach may be too simplified since (unlike requirements
updates) these changes aren't idempotent and so could race with one
another if a lot of releases happen in one go. However, in practice
we only have one job node which creates these and it doesn't run any
jobs in parallel, so we'd never actually see the race. Odds are
we'll just implement a serializing solution for things like this (so
that two jobs with the same name in some specific pipeline won't run
concurrently) if we ever get to the point where we need to
horizontally scale our static nodes, since we probably have more
cases like this already we'll need to solve for.
-- 
Jeremy Stanley