Open Stack

On 26 September 2014 10:28, Zane Bitter <zbitter at redhat.com> wrote:

> 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.

I think bedding them in is great, but sometimes thats more than a
cycle. We benefit if we can decouple 'make big change' from 'big
change is bedded in and ready for users to use'.

> (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 :)

+1.


> 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.

Hmm, this isn't really representative of TripleO's position. We
*want*, *desperately* to be in the integrated gate, and we're nearly
there in terms of donated capacity - we're focusing on on reliability
at the moment. We have no integrated API servers [yet], but Tuskar's
got a very clear plan taking it into the integrated release. Projects
!= Programs :). The non-API-server components of OpenStack as a whole
are mostly not part of the integrated release. The plan with Tuskar
was to get it stable enough to meet the incubation requirements and
then apply. Of course if incubation goes away, thats different :).

> 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.

So as soon as you said that the Board would care about what is in the
integrated release, that re-instates the winners-and-losers thing that
a lot of this discussion is about. And Swift is already on a separate
schedule, but its one of our most popular projects... I think there's
something fundamentally mixed up here :0.

> 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.

I don't understand this at all. If we are rigorous on our backwards
compatibility and semantic versioning of changes any common libraries
can be imported by all those servers. And we have to do that to change
things ourselves safely, so its not like its additional work or
anything.

My big concern here though is the impact on users - as I said in my
blog post, if we introduce instability/inconsistency in terms of what
APIs are widely available or the specific API that is used for e.g.
networking, we make adoption of OpenStack considerably harder.

Monty had a great acid test for this when I was speaking to him the
other day : can users 'bring their own API' or not: ignoring
economy-of-scale arguments, users can bring their own HA DB (if the
compute/container layer exposes anti-affinity scheduling). One can't
replace Nova as a user.

All that said, I'd *love* to see shrinking of the integrated release
process - we've a lot of overheads there, and testing more directly
can get better and faster results.

So I guess I'm saying:

    Lets decouple 'what is openstack' from 'what we test together on
every commit'.

We can debate Ring 0 etc and integrated/decoupled releases etc without
blocking improvements in how we test. As long as we:

 - have confidence in the releases *we do*
 - have some way to signal to projects that their changes would break
someone [ideally before merging to trunk]

we should be fine.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud