Open Stack

On 11/09/15 22:18, matt wrote:
> 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.
>
Matt - every word above is golden. Well said!
>
> On Mon, Nov 9, 2015 at 3:06 PM, Tom Cameron <Tom.Cameron at rackspace.com 
> <mailto: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
>     <mailto:maishsk at maishsk.com>>
>     Sent: Monday, November 9, 2015 14:29
>     To: Tom Cameron; Jeremy Stanley;
>     openstack-operators at lists.openstack.org
>     <mailto: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 <mailto:fungi at yuggoth.org>>
>     > Sent: Monday, November 9, 2015 12:35
>     > To: openstack-operators at lists.openstack.org
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151109/ac828298/attachment.html>