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

Clayton O'Neill clayton at oneill.net
Thu Apr 16 18:15:15 UTC 2015

On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <emilien at redhat.com> wrote:

> We do our best now to backport what is backportable to stable/juno.

This certainly has gotten much better, but I don't think it's 100% there
yet either.  It's just a ton of work and we probably need better tooling
around this to expect it to be as good as it should be.

> FWIW, even without rabbit/kombu topic, master won't work on Juno, there
> is plenty of things that are brought in Kilo.

That may be the case in some areas, but we're using it without issues
(until now) on Ubuntu with the features we need.

> My opinion is we should follow other projects that use stable branches
> with doing deprecation for one (or more?) release (currently our master)
> and then drop the deprecations after some time.
> So I would propose this policy:
> * for new features, patch master with backward compatibility

Agreed, I think some of these might also be candidates for back port if
they're new "module features".  For example a new cinder backend that
existed in the previous release might get back ported if they're just
adding a new class.

> * backports relevant patches from master to stable branches (mainly bugs)

> * in the case of rabbit or any update in OpenStack upstream, update
> master without backward compatibility, except if we accept to have a lot
> of if/else in our code, and a lot of backwards to support; I'm not in
> favor of that.

I think I agree here also.  However, I'd like to see us avoid making
breaking changes solely to avoid deprecation warnings until x amount of
time after a release comes out.  If we're able to support some level of
backwards compatibility, then it also makes upgrading between releases a
lot easier.  Upgrading all of your packages, db schemas, etc is a lot less
scary and easier to test than upgrading all that + every OpenStack puppet
module you use at the same time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/b0fccae9/attachment.html>

More information about the OpenStack-dev mailing list