Open Stack

On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 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.

A fork would be unfortunate. What about a new repo that's just for the
elements used heavily by infra, e.g., openstack-infra-elements.

As you say, the dib interface is pretty stable, are most of the
emergency fixes from the past mostly in elements themselves?

You could have openstack-infra-elements be release:independent, giving
you the freedom to release emergency fixes as quickly as needed.

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

I definitely think dib is part of "OpenStack the Product" given it has
to be used by users and operators of TripleO.

-- 
-- James Slagle
--