Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Donald Talton]

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:t...@bakeyournoodle.com] 
Sent: Thursday, November 05, 2015 11:15 PM
To: OpenStack Development Mailing List
Cc: openstack-operat...@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.
__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Donald Talton]

I agree, but to use your argument: how hard would it be to setup a small group 
to do this for the community? I’m sure there would be a few people interested 
in maintaining it…

From: matt [mailto:m...@nycresistor.com]
Sent: Friday, November 06, 2015 1:18 PM
To: Fox, Kevin M
Cc: Jesse Keating; OpenStack Development Mailing List (not for usage 
questions); openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [stable][all] Keeping Juno 
"alive" for longer.

backporting patches isn't too terribly hard to be honest.  you could probably 
hire a consultant to do it if need be.  mirantis would probably quote you a 
price.

On Fri, Nov 6, 2015 at 3:10 PM, Fox, Kevin M 
> wrote:
Kind of related, as an op, we see a lot of 3rd party repositories that recently 
only supported rhel5 move to finally supporting rhel6 because rhel7 came out 
and rhel5 went to long term support contract only. This caused us to have to 
support rhel5 way longer then we would have liked. Now, we're stuck at 6 
instead of 7. :/

Some number of users will stick with juno until it is EOL and then move. 
Sometimes its because its a desire to not make a change. Sometimes its 
considered a good thing by the ops that they finally have a "good enough" 
excuse (EOL) to move forward "finally" (sigh of relief). :)

Thanks,
Kevin

From: Jesse Keating [j...@bluebox.net]
Sent: Friday, November 06, 2015 10:14 AM
To: Dan Smith
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [stable][all] Keeping Juno 
"alive" for longer.
We (Blue Box, an IBM company) do have a lot of installs on Juno, however we'll 
be aggressively moving to Kilo, so we are not interested in keeping Juno alive.


- jlk

On Fri, Nov 6, 2015 at 9:37 AM, Dan Smith 
> wrote:
> Worth mentioning that OpenStack releases that come out at the same time
> as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
> are supported for 5 years by Canonical so are already kind of an LTS.
> Support in this context means patches, updates and commercial support
> (for a fee).
> For paying customers 3 years of patches, updates and commercial support
> for April releases, (Kilo, O, Q etc..) is also available.

Yeah. IMHO, this is what you pay your vendor for. I don't think upstream
maintaining an older release for so long is a good use of people or CI
resources, especially given how hard it can be for us to keep even
recent stable releases working and maintained.

--Dan

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev