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