[openstack-dev] [tripleo][releases] Remove diskimage-builder from releases
Fox, Kevin M
Kevin.Fox at pnnl.gov
Tue Apr 19 20:09:33 UTC 2016
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. :)
From: James Slagle [james.slagle at 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 <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
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-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev