[openstack-dev] [stable][all] Keeping Juno "alive" for longer.
tony at bakeyournoodle.com
Fri Nov 6 06:15:18 UTC 2015
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.
* According to the current user survey 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
* We only recently EOL'd Icehouse. 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
* 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
* 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: not available
More information about the OpenStack-dev