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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
