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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
