Open Stack

> -----Original Message-----
> From: Tony Breeds [mailto:tony at bakeyournoodle.com]
> Sent: Friday, November 06, 2015 6:15 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operators at lists.openstack.org
> Subject: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.
> 
> 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
> 
> 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.

I'm not big fan of this idea, number of reasons below.
> 
> 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.

I'm working at HPE in the Cloud Engineering team, fwiw.
> 
> 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.

As you say there should some support base for these releases. Unfortunately that has had really small reflection to upstream. It looks like these vendors and operators keep backporting to their own forks, but do not propose the backports to upstream branches, or these installations are not really maintained.
> 
>  * We only recently EOL'd Icehouse[2].  Sure it was well communicated, but
> we
>    still have a huge Icehouse/Juno install base.
> 
> 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.

I leave this point open as I do not know what our plans towards infra are. Perhaps someone could shed some light who does know.
> 
>  * 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.

This has been the main driver for shorter support cycles so far. The group maintaining stable branches is small and at least I haven't seen huge increase on that lately. Stable branches are getting bit more attention again and some great work has been done to ease up the workloads, but same time we get loads of new features and projects in that has affect on infra (resource wise) and gate stability.
> 
>  * 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.

I know lots of people have been waiting this, myself included.
> 
>  * 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.

Both very true.
> 
> 
> 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)?

Based on current status I do not think so.
> 
> Assuming a positive answer:
> 
> 2) Who's going to do the work?
>     - Me, who else?

This is one of the key questions.

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

This was done in YVR, we decided to cut the losses and EOL early.

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

That would be logical thing to do. At least I don't think Juno was anything that special that it would deserve different schedule than Kilo, Liberty, etc.
> 
> Yours Tony.
> 
> [1] http://www.openstack.org/assets/survey/Public-User-Survey-
> Report.pdf
>     (page 20)
> [2] http://git.openstack.org/cgit/openstack/nova/tag/?h=icehouse-eol

I'm really happy seeing this discussion coming up and as it's in my point of view too late to "save" the Juno I'd like to hijack this thread (Not even really sorry about it) and hear how many instances out there are actually planning to dedicate resources on stable branches upstream and can we get stable/kilo & stable/liberty under such maintenance that we can initiate this discussion again _before_ next summit and see if it's viable to review our support plans for the stable releases.

Iiuc there was bit of burnout in the stable maintenance team while ago and some things have been drifting. Ihar has started good discussion about Neutron proactive backporting for this cycle and we have been doing that for Glance for past cycle already with great results. I would like to see people stepping up and expand these plans across at least the core projects of OpenStack over this cycle. I discussed about this with some folks during the Tokyo summit and there seems to be clear interest to make stable branches really stable, not just tag and branch.

If we get enough people maintaining proactively the stable branches, our gates keeps working (as there is actually interest to look after them) and our stable user base would have huge benefit out of this. I do believe it's doable and with all the previous points covered it just might become viable to extend the support period as well. With the current state where most of the backporting happens in the vendor/ops forks and never see daylight in upstream, it's kind of pointless to say that we support release X 12 months more (and by that we just mean that we keep the branch in the tree and keep doing nothing about it).

I keep driving the work for Glance and depending of my time constrains (which are still under discussion) I'm more than willing to spread this out.

Let's make stable sexy again!
Erno jokke_ Kuvaja