Open Stack

On 25/09/14 15:12, Vishvananda Ishaya wrote:
>
> On Sep 24, 2014, at 10:55 AM, Zane Bitter <zbitter at 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.
>>>
>>> http://inaugust.com/post/108
>>
>> 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.

cheers,
Zane.

> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>