<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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). <br>For paying customers 3 years of patches, updates and commercial support for April releases, (Kilo, O, Q etc..) is also available.<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br><br><span style="font-family:trebuchet ms,sans-serif">Best Regards<br><br><br>Mark Baker</span><br></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Nov 6, 2015 at 5:03 PM, James King <span dir="ltr"><<a href="mailto:james@agentultra.com" target="_blank">james@agentultra.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 for some sort of LTS release system.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I’m not sure whether the resources exist to do this but it’d be a nice to have, imho.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Nov 6, 2015, at 11:47 AM, Donald Talton <<a href="mailto:DonaldTalton@fico.com">DonaldTalton@fico.com</a>> wrote:<br>
><br>
> I like the idea of LTS releases.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> -----Original Message-----<br>
> From: Tony Breeds [mailto:<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>]<br>
> Sent: Thursday, November 05, 2015 11:15 PM<br>
> To: OpenStack Development Mailing List<br>
> Cc: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
> Subject: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.<br>
><br>
> Hello all,<br>
><br>
> 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<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Here is a summary of the main points that have come up in my conversations, both for and against.<br>
><br>
> Keep Juno:<br>
> * According to the current user survey[1] Icehouse still has the<br>
> biggest install base in production clouds. Juno is second, which makes<br>
> sense. If we EOL Juno this month that means ~75% of production clouds<br>
> will be running an EOL'd release. Clearly many of these operators have<br>
> support contracts from their vendor, so those operators won't be left<br>
> completely adrift, but I believe it's the vendors that benefit from keeping<br>
> Juno around. By working together *in the community* we'll see the best<br>
> results.<br>
><br>
> * We only recently EOL'd Icehouse[2]. Sure it was well communicated, but we<br>
> still have a huge Icehouse/Juno install base.<br>
><br>
> For me this is pretty compelling but for balance ....<br>
><br>
> Keep the current plan and EOL Juno Real Soon Now:<br>
> * There is also no ignoring the elephant in the room that with HP stepping<br>
> back from public cloud there are questions about our CI capacity, and<br>
> keeping Juno will have an impact on that critical resource.<br>
><br>
> * Juno (and other stable/*) resources have a non-zero impact on *every*<br>
> project, esp. @infra and release management. We need to ensure this<br>
> isn't too much of a burden. This mostly means we need enough trustworthy<br>
> volunteers.<br>
><br>
> * Juno is also tied up with Python 2.6 support. When<br>
> Juno goes, so will Python 2.6 which is a happy feeling for a number of<br>
> people, and more importantly reduces complexity in our project<br>
> infrastructure.<br>
><br>
> * Even if we keep Juno for 6 months or 1 year, that doesn't help vendors<br>
> that are "on the hook" for multiple years of support, so for that case<br>
> we're really only delaying the inevitable.<br>
><br>
> * Some number of the production clouds may never migrate from $version, in<br>
> which case longer support for Juno isn't going to help them.<br>
><br>
><br>
> 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:<br>
><br>
> 1) Is it even possible to keep Juno alive (is the impact on the project as<br>
> a whole acceptable)?<br>
><br>
> Assuming a positive answer:<br>
><br>
> 2) Who's going to do the work?<br>
> - Me, who else?<br>
> 3) What do we do if people don't actually do the work but we as a community<br>
> have made a commitment?<br>
> 4) If we keep Juno alive for $some_time, does that imply we also bump the<br>
> life cycle on Kilo and liberty and Mitaka etc?<br>
><br>
> Yours Tony.<br>
><br>
> [1] <a href="http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf" rel="noreferrer" target="_blank">http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf</a><br>
> (page 20)<br>
> [2] <a href="http://git.openstack.org/cgit/openstack/nova/tag/?h=icehouse-eol" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tag/?h=icehouse-eol</a><br>
><br>
><br>
> 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.<br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>