[Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
mark.baker at canonical.com
Fri Nov 6 17:28:13 UTC 2015
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.
On Fri, Nov 6, 2015 at 5:03 PM, James King <james at agentultra.com> wrote:
> +1 for some sort of LTS release system.
> Telcos and risk-averse organizations working with sensitive data might not
> be able to upgrade nearly as fast as the releases keep coming out. From the
> summit in Japan it sounds like companies running some fairly critical
> public infrastructure on Openstack aren’t going to be upgrading to Kilo any
> time soon.
> Public clouds might even benefit from this. I know we (Dreamcompute) are
> working towards tracking the upstream releases closer… but it’s not
> feasible for everyone.
> I’m not sure whether the resources exist to do this but it’d be a nice to
> have, imho.
> > On Nov 6, 2015, at 11:47 AM, Donald Talton <DonaldTalton at fico.com>
> > 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
> > 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 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
> > Juno around. By working together *in the community* we'll see the best
> > results.
> > * 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
> > 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
> > 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,
> > 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
> > 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
> > 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.
> >  http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
> > (page 20)
> >  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
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators