Open Stack

Excerpts from Tony Breeds's message of 2015-11-05 22:15:18 -0800:
> Hello all,
> 
> I'll start by acknowledging that this is a big and complex issue and I
> do not claim to be across all the view points, nor do I claim to be
> particularly persuasive ;P
> 

<ahem> In the future, also consider not making it even more complex by
cross posting!

Indeed, it is not cut and dry.

> Having stated that, I'd like to seek constructive feedback on the idea of
> keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.
> 

While I wish everybody would get on the Continuous Delivery train, I
understand that it's still comforting to many to use stable releases with
the hope that this will somehow keep them more available (it won't, there
are more scalability and reslience bugs fixed than "big risky changes"
landed by quite a large factor, in trunk) or that it will be less change
(it isn't, you can eat the elephant one spoon-full at a time, or prepare
a feast every 6 months).

Until we all embrace the chaos-drip in favor of the chaos-deluge, we
have to keep supporting stable releases.

> Acknowledging my affiliation/bias:  I work for Rackspace in the private
> cloud team.  We support a number of customers currently running Juno that are,
> for a variety of reasons, challenged by the Kilo upgrade.
> 
> Here is a summary of the main points that have come up in my conversations,
> both for and against.
> 
> Keep Juno:
>  * According to the current user survey[1] Icehouse still has the
>    biggest install base in production clouds.  Juno is second, which makes
>    sense. If we EOL Juno this month that means ~75% of production clouds
>    will be running an EOL'd release.  Clearly many of these operators have
>    support contracts from their vendor, so those operators won't be left 
>    completely adrift, but I believe it's the vendors that benefit from keeping
>    Juno around. By working together *in the community* we'll see the best
>    results.
> 
>  * We only recently EOL'd Icehouse[2].  Sure it was well communicated, but we
>    still have a huge Icehouse/Juno install base.
> 

Wow, yeah, I had not seen these numbers yet. It sounds to me like the
number of operators who can keep up with the 6 month cadence is very low,
and LTS cycles need to be considered.

> For me this is pretty compelling but for balance .... 
> 
> Keep the current plan and EOL Juno Real Soon Now:
>  * There is also no ignoring the elephant in the room that with HP stepping
>    back from public cloud there are questions about our CI capacity, and
>    keeping Juno will have an impact on that critical resource.
> 
>  * Juno (and other stable/*) resources have a non-zero impact on *every*
>    project, esp. @infra and release management.  We need to ensure this
>    isn't too much of a burden.  This mostly means we need enough trustworthy
>    volunteers.
> 
>  * Juno is also tied up with Python 2.6 support. When
>    Juno goes, so will Python 2.6 which is a happy feeling for a number of
>    people, and more importantly reduces complexity in our project
>    infrastructure.
> 
>  * Even if we keep Juno for 6 months or 1 year, that doesn't help vendors
>    that are "on the hook" for multiple years of support, so for that case
>    we're really only delaying the inevitable.
> 
>  * Some number of the production clouds may never migrate from $version, in
>    which case longer support for Juno isn't going to help them.
> 
> 
> I'm sure these question were well discussed at the VYR summit where we set
> the EOL date for Juno, but I was new then :) What I'm asking is:
> 
> 1) Is it even possible to keep Juno alive (is the impact on the project as
>    a whole acceptable)?
> 

Sure, but...

> Assuming a positive answer:
> 
> 2) Who's going to do the work?
>     - Me, who else?

That's really the rub. Historically barely anybody has maintained the
stable branches, though lately that has gotten a bit better.

> 3) What do we do if people don't actually do the work but we as a community
>    have made a commitment?

There's certainly an argument to be made for downstream entities to take
this over if we, upstream, don't want it.

> 4) If we keep Juno alive for $some_time, does that imply we also bump the
>    life cycle on Kilo and liberty and Mitaka etc?
> 

Probably. Doesn't seem like this problem can go away without making
concessions for longer term support though. One concession might be that
6 months is too short, and extend the cycle out. But that would have
gigantic ripple effects.