On Fri, Nov 6, 2015 at 12:28 PM, Mark Baker <mark.ba...@canonical.com> 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. >
Does that mean that you are actually backporting and gate testing patches downstream that aren't being done upstream? I somehow doubt it, but if so, then it would be great if you could lead some sort of initiative to push those patches back upstream. -Erik > > > Best Regards > > > Mark Baker > > On Fri, Nov 6, 2015 at 5:03 PM, James King <ja...@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 <donaldtal...@fico.com> >> > wrote: >> > >> > 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-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 > > > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > __________________________________________________________________________ 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