Open Stack

On Fri, Nov 6, 2015 at 12:28 PM, Mark Baker <mark.baker at 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 <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>
>> > 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: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
>> > 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-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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>