Open Stack

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

>
>
> On 04/16/2015 12:26 AM, Matt Fischer wrote:
> > 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.
>
> We do our best now to backport what is backportable to stable/juno.
>
> > 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.
>
Since I started working on this project I was under the impression that
master tracks the next unreleased version of OpenStack. I don't recall
where I got this impression and I don't believe it is documented, but I
think it makes sense. If we didn't do this, we would have to wait for
months after a release to make breaking changes. Master is not supposed to
be stable, that is what stable branches are for.

However, I am sympathetic to the problem, as I don't have access to
pre-release upstream packages and I have to check out old commits in order
to do development. I would be in favor of adding conditionals for
deprecated parameters, even though it would probably end up being messy.
Deprecated is deprecated, not invalid, so I agree that we should probably
allow them for a release cycle.

>
> FWIW, even without rabbit/kombu topic, master won't work on Juno, there
> is plenty of things that are brought in Kilo.
>
> 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
> * 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 would like to additionally propose that we assign responsibility for
backports so that these changes don't just get left behind and forgotten
about. The author of the patch should add some sort of tag to indicate that
something is a bugfix, a backwards compatible feature, or a
backwards-incompatible change. The approver of the patch must take
responsibility for cherry-picking the patch to the stable branch if it is
backwards compatible.

>
> > 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.
> >
>
> It's on the agenda for Tuesday's meeting (thanks Matt for this).
> In the meantime, any feedback is welcome,
>
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> Emilien Macchi
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Thanks for bringing this up.

Colleen (crinkle)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/d666cd8f/attachment-0001.html>