On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley <fu...@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 -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
