Open Stack

I like the idea of LTS releases. 

Speaking to my own deployments, there are many new features we are not interested in, and wouldn't be, until we can get organizational (cultural) change in place, or see stability and scalability. 

We can't rely on, or expect, that orgs will move to the CI/CD model for infra, when they aren't even ready to do that for their own apps. It's still a new "paradigm" for many of us. CI/CD requires a considerable engineering effort, and given that the decision to "switch" to OpenStack is often driven by cost-savings over enterprise virtualization, adding those costs back in via engineering salaries doesn't make fiscal sense.

My big argument is that if Icehouse/Juno works and is stable, and I don't need newer features from subsequent releases, why would I expend the effort until such a time that I do want those features? Thankfully there are vendors that understand this. Keeping up with the release cycle just for the sake of keeping up with the release cycle is exhausting.

-----Original Message-----
From: Tony Breeds [mailto:tony at bakeyournoodle.com] 
Sent: Thursday, November 05, 2015 11:15 PM
To: OpenStack Development Mailing List
Cc: openstack-operators at lists.openstack.org
Subject: [Openstack-operators] [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.

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.

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

Assuming a positive answer:

2) Who's going to do the work?
    - Me, who else?
3) What do we do if people don't actually do the work but we as a community
   have made a commitment?
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?

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


This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.