As an Op, I've been bitten by both sides of this.... I've seen dib updated and broken things. I've seen dib elements updated and things broke (centos6 removal in particular hurt.) I've appreciated dib elements getting fixed quickly at times because distro's changed, and the element needed change too and so I didn't have to continue to work around issues.
So, I can't say which way forward is best. Just that care has to be taken in all cases. :) Thanks, Kevin ________________________________________ From: James Slagle [james.sla...@gmail.com] Sent: Tuesday, April 19, 2016 12:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases 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 __________________________________________________________________________ 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
