Open Stack

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.
>
> 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.

Matt,

I am certainly sympathetic to your situation - having the world change 
beneath your feet is never a good place to be. =]

It does seem, however, that there is a disconnect between your 
expectations (as I understand them) of what the 'master' branch 
represents, and what it has traditionally represented - the 'bleeding edge'

Master is volatile - it is expected to be volatile. As the code 
progresses between releases it is expected that things can (and will) break.

The solution, in my mind, is not to redefine what it means to be master, 
but rather to be more aggressive about back-porting changes to stable 
branches.

I am very much in favor of discussions that include your proposed 
solution above (i.e. 'current-1' support), as long as it is identified 
as a transitional step; I do pretty strongly believe that the right 
long-term model is to treat master as the 'bleeding edge' and to only 
pin yourself to stable releases.

Regards,

Richard Raseley

SysOps Engineer
Puppet Labs