Open Stack

Excerpts from Jeremy Stanley's message of 2016-04-19 15:41:26 +0000:
> On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000:
> [...]
> > > I don't expect the stable release team to be involved with all this;
> > > but if we miss windows then we're left either going to efforts getting
> > > one of a handful of people with permissions to do manual rebuilds or
> > > waiting yet another day to get something fixed.  Add some timezones
> > > into this, and simple fixes are taking many days to get into builds.
> > > Thus adding points where we can extend this by another 24 hours
> > > really, well, sucks.
> > 
> > How often does that situation actually come up?
> 
> Semi-often. The project is officially under TripleO but it's sort of
> a shared jurisdiction between some TripleO and Infra contributors. I
> think the release team for diskimage-builder used to shoot for
> tagging weekly (sans emergencies), though that's slacked off a bit
> and is more like every 2 weeks lately.

That's about the same as or less often than we tag Oslo libraries.

> DIB is an unfortunate combination of a mostly stable framework and a
> large pre-written set of scripts and declarative data which is
> constantly evolving for widespread use outside the OpenStack
> ecosystem (so most of the change volume is to the latter). As Ian
> points out, the Infra team has already been tempted to stop relying
> on DIB releases at all (or worse, maintain a fork) to reduce overall
> latency for getting emergency fixes reflected in our worker images.

Sure, that's a compelling argument. I'm not opposed to making it easier
for timely releases, just trying to understand the pressure.

> I suspect that most of the concern over using OpenStack release
> process for DIB (and similarly Infra projects) is that the added
> complexities introduce delays, especially if there's not a release
> team member available to do on-the-spot approvals on weekends and
> such. I don't know whether extending that to add tagging ACLs for
> the library-release group would help? That would bring the total up
> to 6 people, two more of whom are in non-American timezones, so
> might be worth a try.
> 
> It's also worth keeping in mind that we've sort of already
> identified two classes of official OpenStack projects. One is
> "OpenStack the Product" only able to be distributed under the Apache
> license and its contributors bound by a contributor license
> agreement. The other is the output of a loose collective of groups
> writing ancillary tooling consumed by the OpenStack community and
> also often used for a lot of other things completely unrelated to
> OpenStack. I can see where strict coordinated release process and
> consistency for the former makes sense, but a lot of projects in the
> latter category likely see it as unnecessary overkill for their
> releases.

It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org. Centralizing tagging
also helps us ensure consistent versioning rules, good timing, good
release announcements, etc.

Since dib is part of tripleo, and at least 2 other projects depend
on it directly (sahara-image-elements and manila-image-elements),
I would expect the tripleo team to want it included on the site,
to publish release announcements, etc.

On the other hand, dib is using the release:independent model, which
indicates that the team in fact doesn't think it should be considered
part of the "product." Maybe we can use that as our flag for which
projects should really be managed by the release team and which
should not, but we don't want projects that want to be part of official
releases to use that model.

With what I know today, I can't tell which side of the line dib is
really on. Maybe someone can clarify?

Doug