Open Stack

=D

On Mon, Nov 9, 2015 at 3:43 PM, Tom Cameron <Tom.Cameron at rackspace.com>
wrote:

> YOLO. Because it's in The Cloud.
>
>
>
> --
> Tom Cameron
>
>
>
> ------------------------------
> *From:* Donald Talton <DonaldTalton at fico.com>
> *Sent:* Monday, November 9, 2015 15:41
> *To:* matt; Tom Cameron
> *Cc:* openstack-operators at 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:matt at nycresistor.com]
> *Sent:* Monday, November 09, 2015 1:18 PM
> *To:* Tom Cameron
> *Cc:* openstack-operators at 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.Cameron at 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 <maishsk at maishsk.com>
> Sent: Monday, November 9, 2015 14:29
> To: Tom Cameron; Jeremy Stanley; openstack-operators at 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 <fungi at yuggoth.org>
> > Sent: Monday, November 9, 2015 12:35
> > To: openstack-operators at 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 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
>
> --
> Best Regards,
> Maish Saidel-Keesing
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151109/305dcc84/attachment-0001.html>