=D On Mon, Nov 9, 2015 at 3:43 PM, Tom Cameron <tom.came...@rackspace.com> wrote:
> YOLO. Because it's in The Cloud. > > > > -- > Tom Cameron > > > > ------------------------------ > *From:* Donald Talton <donaldtal...@fico.com> > *Sent:* Monday, November 9, 2015 15:41 > *To:* matt; Tom Cameron > *Cc:* openstack-operators@lists.openstack.org > *Subject:* RE: [Openstack-operators] [openstack-dev] [stable][all] > Keeping Juno "alive" for longer. > > > All good points, but I’m not sure about the 3-5 window…it’s so anti-cloud. > Although I think many of us are not doing cloudy things with OpenStack. > > > > That said, RedHat’s stable OSP releases are trailing 6mos behind community > releases. And many of us do site-stability testing that lasts for months > before actually going live. And many of us just YOLO cloud it and do > upgrades in place, but I think this is fairly rare. > > > > I wouldn’t ask for 3-5 year coverage..but 18-24 mos sure would be nice. > > > > > > *From:* matt [mailto:m...@nycresistor.com] > *Sent:* Monday, November 09, 2015 1:18 PM > *To:* Tom Cameron > *Cc:* openstack-operators@lists.openstack.org > *Subject:* Re: [Openstack-operators] [openstack-dev] [stable][all] > Keeping Juno "alive" for longer. > > > > Hell. There's no clear upgrade path, and no guaranteed matched > functionality just for starters. > > > > Also most enterprise deployments do 3 to 5 year deployment plans. This > ties into how equipment / power / resources are budgeted in the project > plans. They don't work with this mentality of rapid release cycles. > > > > We assumed early on that the people deploying OpenStack would be more > agile because of the ephemeral nature of cloud. That's not really what's > happening. There are good and bad reasons for that. One good reason is > policy certification. By the time a team has prepped, built, tested an > environment and is moving to production it's already been an entire release > ( or two since most ops refuse to use a fresh release for stability reasons > ). By the time it passes independent security / qa testing and development > workflows for deploying apps to the environment it's been 3-4 releases or > more. But more often than not the problem is most of the VM workloads > aren't good with ephemeral and mandating downtime on systems is an onerous > change control process. Making the upgrade process for the environment > very difficult and time consuming. > > > > More than that vendors that provide extra ( sometimes necessary ) > additions to openstack, such as switch vendors take at least a few months > to test a new release and certify their drivers for deployment. Most folks > aren't even beginning to deploy a fresh release of openstack EVEN if they > wanted to until it's been out for at least six months. It's not like they > can really test pre-rc releases and expect their tests to mean anything. > > > > There's almost no one riding the wave of new deployments. > > > > > > On Mon, Nov 9, 2015 at 3:06 PM, Tom Cameron <tom.came...@rackspace.com> > 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. > > 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 > > > > 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
