On 11/09/15 22:06, Tom Cameron wrote:
I would not call that the extreme minority.
I would say a good percentage of users are on only getting to Juno now.
The survey seems to indicate lots of people are on Havana, Icehouse and Juno in
production. I would love to see the survey ask _why_ people are on older versions because
for many operators I suspect they forked when they needed a feature or function that
didn't yet exist, and they're now stuck in a horrible parallel universe where upstream
has not only added the missing feature but has also massively improved code quality.
Meanwhile, they can't spend the person hours on either porting their work into the new
Big Tent world we live in, or can't bare the thought of having to throw away their hard
earned tech debt. For more on this, see the myth of the "sunken cost".
If it turns out people really are deploying new clouds with old versions on
purpose because of a perceived stability benefit, then they aren't reading the
release schedule pages close enough to see that what they're deploying today
will be abandoned soon in the future. In my _personal_ opinion which has
nothing to do with Openstack or my employer, this is really poor operational
due diligence.
I don't think people are deploying old clouds or old versions.
They are just stuck on older versions. Why (as matt said in his reply)
the upgrade process is hell! And when your environment grows past a
certain point if you have have to upgrade say 100 hosts, it can take a
good couple of months to get the quirks fixed and sorted out, and then
you have to start all over again, because the next release just came out.
A constant game of chasing your tail to keep up with the technology, is
one that some are not willing to play (or are not capable of playing
either).
If, however, a deployer has been working on a proof of concept for 18-24 months
and they're now ready to go live with their cloud running a release from 18-24
months ago, I have sympathy for them. The bigger the deployment, the harder
this one is to solve which makes it a prime candidate for the LTS strategy.
Either way, we've lost the original conversation long ago. It sounds like we
all agree that an LTS release strategy suits most needs but also that it would
take a lot of work that hasn't yet been thought of or started. Maybe there
should be a session in Austin for this topic after blueprints are submitted and
discussed? It would be nice to have the operators and developers input in a
single place, and to get this idea on the radar of all of the projects.
--
Tom Cameron
________________________________________
From: Maish Saidel-Keesing <mais...@maishsk.com>
Sent: Monday, November 9, 2015 14:29
To: Tom Cameron; Jeremy Stanley; openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [stable][all] Keeping Juno
"alive" for longer.
On 11/09/15 21:01, Tom Cameron wrote:
From your other thread...
Or else you're saying you intend to fix the current inability of our projects
to skip intermediate releases entirely during upgrades
I think without knowing it, that's what most would be suggesting, yeah. Of
course, like you mentioned, the real work is in how upgrades get refactored to
skip intermediate releases (two or three of them).
DB schema changes can basically be rolled up and kept around for a while, so
that's not too be a problem. Config files OTOH have no schema or schema
validator, so that would require tooling and all kinds of fun (bug prone)
wizardry.
This is all solvable, but it adds complexity for the sake of what I can only
imagine are the extreme minority of users. What do the user/operator surveys
say about the usage of older releases? What portion of the user base is
actually on releases prior to Havana?
I would not call that the extreme minority.
I would say a good percentage of users are on only getting to Juno now.
--
Tom Cameron
________________________________________
From: Jeremy Stanley <fu...@yuggoth.org>
Sent: Monday, November 9, 2015 12:35
To: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [stable][all] Keeping Juno
"alive" for longer.
On 2015-11-09 17:11:35 +0000 (+0000), Tom Cameron wrote:
[...]
I support an LTS release strategy because it will allow more
adoption for more sectors by offering that stability everyone's
talking about. But, it shouldn't be a super-super long support
offering. Maybe steal some of Ubuntu's game and do an LTS every 4
releases or so (24 months), but then maybe Openstack only supports
them for 24 months time? Again, my concern is that this is free,
open source software and you're probably not going to get many
community members to volunteer to offer their precious time fixing
bugs in a 2-year-old codebase that have been fixed for 18 months
in a newer version.
[...]
Because we want people to be able upgrade their deployments, the
problem runs deeper than just backporting some fixes to a particular
branch for longer periods of time. Unfortunately the original poster
cross-posted this thread to multiple mailing lists so the discussion
has rapidly bifurcated, but I addressed this particular topic in my
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078735.html
reply.
--
Jeremy Stanley
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Best Regards,
Maish Saidel-Keesing
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Best Regards,
Maish Saidel-Keesing
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
