[openstack-dev] [puppet] rabbit/kombu settings deprecations

Matt Fischer matt at mattfischer.com
Thu Apr 16 04:26:04 UTC 2015


Recently a mass of changes was proposed and some merged to move the
rabbit/kombu settings to avoid a Kilo deprecation. As far as I can tell
this will break rabbit connectivity for all modules still using Juno. I did
an experiment with Heat and it certainly can't talk to rabbit anymore.
(Hopefully you guys can just tell me I'm wrong here and everything will
still work)

So why did we do this? We seem to have traded a slightly annoying
deprecation warning for breaking every single module. It does not seem like
a good trade-off to me. At a minimum, I would have liked to wait until we
had forked Kilo off and we're working towards Liberty. Why? Because there
was simply no pressing reason to do this right now when most everyone is
still using Juno.

Since we as a community are pretty terrible at backports, this means that I
now need to switch to stable and sit on old and non-updated code until I
can upgrade to Kilo, which is likely a minimum of 45 days away for many
components for us.

This has implications for my team beyond breaking everything:

* It means that we need to stop importing puppet code changes with our
git-upstream jobs. This makes the process of moving back to master when we
finally can quite painful. I had to do it for Icehouse and I don't relish
doing it again.

* It means that any fixes we want will require a two step process to get
into backports. This delays things obviously.

* It means that the number of contributions you will get from us will
probably fall, not being on master makes it way more likely for us just to
hold patches.

* It means that we will have to write a shim layer in our module to deal
with these settings and whatever else gets broken like this.

So I'd like to discuss the philosophy of why this was done. I'd also again
like to put in my vote for master supporting current-1 for at least some
period of time. There's a reason that the upstream code that we configure
just did this with a deprecation rather than a "if you set it like this you
are broken". We should do the same.

For now I've -1'd all the outstanding reviews until we can have a
discussion about it. I know one was merged despite my -1, but I didn't
think a -2 was warranted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150415/1f13535f/attachment.html>


More information about the OpenStack-dev mailing list