On 25/09/14 15:12, Vishvananda Ishaya wrote:

On Sep 24, 2014, at 10:55 AM, Zane Bitter <zbit...@redhat.com> wrote:

On 18/09/14 14:53, Monty Taylor wrote:
Hey all,

I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough to help me edit.


I think there are a number of unjustified assumptions behind this arrangement 
of things. I'm going to list some here, but I don't want anyone to interpret 
this as a personal criticism of Monty. The point is that we all suffer from 
biases - not for any questionable reasons but purely as a result of our own 
experiences, who we spend our time talking to and what we spend our time 
thinking about - and therefore we should all be extremely circumspect about 
trying to bake our own mental models of what OpenStack should be into the 
organisational structure of the project itself.

I think there were some assumptions that lead to the Layer1 model. Perhaps a 
little insight into the in-person debate[1] at OpenStack-SV might help explain 
where monty was coming from.

Thanks Vish, that is indeed useful background. Apparently I need to get out more ;)

The initial thought was a radical idea (pioneered by Jay) to completely 
dismantle the integrated release and have all projects release independently 
and functionally test against their real dependencies. This gained support from 
various people and I still think it is a great long-term goal.

So it goes without saying that I support the latter part ("functionally test against their real dependencies"). I'm not convinced by the idea of not having an integrated release though. Time-based releases seem to be pretty popular lately - the Linux kernel, most distributions and the two major open-source web browsers use them, for example - and as a developer I don't feel especially qualified to second-guess what the release schedule for a particular component should actually be. The current cycle works decently well, is not obviously worse than any particular alternative, and aligns semi-nicely with the design summits (FWIW I think I would actually prefer the design summit take place _before_ the release, but that is a whole other discussion).

We actually discussed with Monty at this week's Heat meeting his proposal to move the UI projects to a continuous release schedule. (For the moment Heat is actually blocked on severe limitations in the usefulness of standalone mode, but we expect those to shake out over the near term anyway.) I think there was general agreement that there would be some big upsides - it really sucks telling the 15th user that we already redesigned that thing to solve your issue like 4 months ago, but since you're stuck on Icehouse we can't help. On the other hand, there's big downsides too. We're still making major changes, and it's really nice to be able to let them bed in as part of a release cycle.

(Since I started this discussion talking about bias, it's worth calling out a *huge* one here: my team has to figure out a way to package and distribute this stuff.)

That said, if we can get to a situation where we *choose* to do a co-ordinated release for the convenience of developers, distributors and (hopefully) users - rather than being forced into it through sheer terror that everything will fall over in a flaming heap if we don't - that would obviously be a win :)

The worry that Monty (and others) had are two-fold:

1. When we had no co-gating in the past, we ended up with a lot of 
cross-project breakage. If we jump right into this we could end up in the wild 
west were different projects expect different keystone versions and there is no 
way to deploy a functional cloud.
2. We have set expectations in our community (and especially with 
distributions), that we release a set of things that all work together. It is 
not acceptable for us to just pull the rug out from under them.

These concerns show that we must (in the short term) provide some kind of 
integrated testing and release. I see the layer1 model as a stepping stone 
towards the long term goal of having the projects release independently and 
depend on stable interfaces. We aren’t going to get there immediately, so 
having a smaller, integrated set of services representing our most common use 
case seems like a good first step. As our interfaces get more stable and our 
testing gets better it could move to a (once every X months) release that just 
packages the current version of the layer1 projects or even be completely 
managed by distributions.

We need a way to move forward, but I’m hoping we can do it without a concept of 
“specialness” around layer1 projects. I actually see it as a limitation of 
these projects that we have to take this stepping stone and cannot disaggregate 
completely. Instead it should be seen as a necessary evil so that we don’t 
break our users.

Right, if we _have_ to have it let's not name it something aspirational like "Layer 1" or "ring 0". Let's call it "Cluster Foxtrot" and make sure that projects are queueing up to get _out_. We can start with Designate, which afaik has done nothing to bring upon themselves such a fate ;)

I'm not convinced that it has to be a formal, named thing though. In terms of the gating thing, that would be an organisational solution to a purely technical problem: up to now there's been no middle ground between a cluster of projects that all gate against each other and just not gating against each other at all. I'm totally confident that the QA and Infra teams can fix that. Those folks are superb at what they do.

And on the release side, I think we're running before we can walk. It's not clear that most, or even many, projects would want to abandon a co-ordinated release anyway. (I'd actually have no problem with letting projects opt-out if they have some reason to - TripleO already effectively did.) External stakeholders (including the board) would _inevitably_ treat a shrinking of the co-ordinated release as an endorsement of which projects we actually care about, and by extension which projects they should care about.

If we ever reach a point where interfaces are stable enough that we don't need a co-ordinated release, let's consider _then_ whether to tear the whole thing down - in one fell swoop. Taking a half-measure sends exactly the wrong signal.

TBH, though, I don't think we're likely to ever make that choice (though more projects may be able to move to a Swift-like release model over time). There's a lot more to testing that your project integrates with another one than just making sure it presents the interface it thought it was presenting. At some point you have to try it - though hopefully we eventually won't need to try it *on every commit* any more - and a co-ordinated release can help a lot with simplifying that.

Finally, I would add that unco-ordinated releases, where distributions have to select a set of components that synced to the global requirements at different times, are not going to be truly feasible until we have a container-based deployment system. I expect it to not be an issue in the future, but that work is only just getting underway.

For all of those reasons, I think shrinking the co-ordinated release is premature.


In addition, we should encourage other shared use cases in openstack both for 
testing (functional tests against groups of services) and for releases (shared 
releases of related projects).

[1] Note this wasn’t a planned debate, but a spontaneous discussion that 
included (at various points) Monty Taylor, Jay Pipes, Joe Gordon, John 
Dickenson, Myself, and (undoubtedly) one or two people I”m forgetting.

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to