Open Stack

Excerpts from Tony Breeds's message of 2017-02-01 21:18:54 +1100:
> On Wed, Jan 18, 2017 at 04:34:56PM -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.
> 
> Dirk's been doing a great job of dealing with that and there are scripts to
> take the ones generated from the bot and make single series from them n deep.
> That's not very sustainable though.
> 
> <snip>
> 
> > The final option uses a SHA1 hash of the name as the sort key. It
> > wouldn't be easy for a human to update the file by hand, but we
> > could make a tool that does. I don't know how often that case comes
> > up, so I don't know how important it is. See
> > https://review.openstack.org/422245 and https://review.openstack.org/422246
> > for the sample output.
> 
> Thanks Doug.  I like this option.
> 
> We don't need to add a tool as the docs describe how to do this already, which
> basically boils down to run the tool you're patching.
> 
> If that doesn't happen (which is common) the next daily update will just move
> it to the new right place.
> 
> I think we should do this early after we branch requirements
> 
> Yours Tony.

While debugging the issues, although we learned that we're less
likely to have collisions by changing the order, it's not going to
be sufficient to deal with the problem posed when we have an Oslo
release set. Zuul is limited to managing 6 "unrelated" patches when
merging, so when we have more than 6 patches trying to merge it
will throw an error that looks like a conflict, even though there
isn't one.

We discussed (on IRC) a couple of options:

One is to do away with the proposals as part of the release jobs,
and rely on the daily update. I'm not sure I like that, because it
means if the update fails any tests we aren't introducing new
versions of our libraries quickly. Debugging that class of failure
is a job we've had a hard time recruiting people to help with, so
while the current team has been doing a great job staying on top
of it, I worry about what will happen when they get tired of doing
it. We did also discuss changing the frequency of the automatic
updates, but I think I was talked out of that on the grounds that
it takes us a day to get the patch reviewed and merged anyway so
running it more often would introduce delays because we would lose
review votes.

Another option was to have the release bot continually propose
updates to the same patch, like we do with the global requirements
sync job. On any given day, that's going to cause a bunch of resets
on the patch, until we merge it. That will be particularly annoying
if we release something while the patch is in the gate queue ready
to be merged, but even in the check queue it will "waste" test nodes
on each reset.

The third option suggested was to submit the updates in a series.
That allows us to merge them one at a time, and avoids the limit-of-6
issue because the patches are all related in a series. If something
fails, we can remove it from the series by hand and debug it
separately.

I've put this topic on the etherpad for the stable/requirements/release
team meetup at the PTG.

Doug