Open Stack

On 11/21/2013 01:58 AM, Thierry Carrez wrote:
> Mark Washenberger wrote:
>> [...]
>> In order to mitigate that risk, I think it would make a lot of sense to
>> have a place to stage and carefully consider all the breaking changes we
>> want to make. I also would like to have that place be somewhere in
>> Gerrit so that it fits in with our current submission and review
>> process. But if that place is the 'master' branch and we take a long
>> time, then we can't really release any bug fixes to the v0 series in the
>> meantime.
>>
>> I can think of a few workarounds, but they all seem kinda bad. For
>> example, we could put all the breaking changes together in one commit,
>> or we could do all this prep in github.
>>
>> My question is, is there a correct way to stage breaking changes in
>> Gerrit? Has some other team already dealt with this problem?
>> [...]
> 
> It sounds like a case where we could use a feature branch. There have
> been a number of them in the past when people wanted to incrementally
> work on new features without affecting master, and at first glance
> (haha) it sounds appropriate here. Infra team, thoughts ?

Hi!

This is a really complex one because of the gate. It's not just about
the semver major version bump. I agree with earlier sentiment - the way
to handle breaking changes is to bump the major version, and on the
surface I don't have a problem with us doing that, since there is
already a mechanism to deal with that.

HOWEVER - it's more complex than that with us, because the client libs
are part of our integration.

We've already agreed on and have been operating on the assumption that
client libs do not break rest api backwards compat. We're 3 seconds away
from landing gating tests to ensure this is the case. The reasoning here
is that an end user of OpenStack should not need to know what version of
OpenStack a vendor is running - the latest python-glanceclient should
work with diablo and it should work with icehouse. Nothing in this
thread breaks that - I just bring it up because it's one of the overall
design points that we'll be rubbing against.

Now, in the gate, without bringing backwards compat into the picture -
we test master against master, and stable/havana against stable/havana
across all the projects. If a project (like a client lib) doesn't have a
stable/havana, we use its master branch - this is how master client lib
is tested against stable/grizzly and stable/havana right now. And I
don't just mean as an end-user test - I mean that we deploy devstack for
stable/grizzly with master python-glanceclient and that's what any of
the other projects that need to talk to glance (heat, horizon) uses.

We do not pin uses of the client libs in stable branches - because we
actually explicitly want to gate on the combination, and we want to be
sure that releasing a new version of glanceclient does not break
someone's grizzly deployment.

With all of that background ...

In order to consider a set of changes that would be a major version bump
for the client libs, we're going to have to figure out what the testing
matrix looks like (as in, what do we _want_ to test with each other) and
we're going to have to figure out how to orchestrate that in the logic
that prepares sets of branches to be tested with each other in the gate.

For dev, there are two approaches - we can make a
feature/glanceclient-2.0 branch, and leave master as it is, or we can
make a stable/1.0 branch and do the breaking work on master.

If we do the stable/1.0 approach, we'd probably have to go pin
stable/grizzly and stable/havana at <=2.0. Problem is, I don't know how
to tell devstack gate that stable/grizzly and stable/havana want
glanceclient stable/1.0

Alternately, if we do the feature branch, we can avoid thinking about
the stable problem for a minute, but we still gate feature branch
patches - so you'd have to figure out how to deal with the fact that the
feature branch would be gating against master of the other projects.

Why don't we just stop cross-gating on the client libs and have our
servers consume releases of our clients? Well, that's because they'd be
requesting different versions of them at different times. We need to
make sure that the client libs can't land changes that break the server
projects BEFORE they release, because otherwise the
tag/release/tag/re-release cycle would kill us.

In any case, sorry for the novel, this request is PARTICULARLY complex
to work through, as "backwards incompat client library changes" is a
thing we explicitly designed the integrated gate to consider would never
happen. I understand the request, and like I said, it's not unreasonable
on its face - but it's going to take some brain time from the infra team
I believe ... and fixing the current race conditions has been priority
number one this week...

That said - bear with us here - if you can hang on for a bit until we've
got some space to properly brainstorm about what the physical
possibilities are, we can come back with some suggestions and
descriptions of what the tradeoffs are (in a way that doesn't resemble
me sitting in bed at 5:30am typing rambling emails)

Thanks!
Monty