<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 11/09/15 22:18, matt wrote:<br>
<blockquote
cite="mid:CAP_sDUHd1Y2omek-ii7P1NJFc_SZgbqV4N7FvK33apXOyrhY6g@mail.gmail.com"
type="cite">
<div dir="ltr">Hell. There's no clear upgrade path, and no
guaranteed matched functionality just for starters.
<div><br>
</div>
<div>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.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>There's almost no one riding the wave of new
deployments.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
Matt - every word above is golden. Well said!<br>
<blockquote
cite="mid:CAP_sDUHd1Y2omek-ii7P1NJFc_SZgbqV4N7FvK33apXOyrhY6g@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 9, 2015 at 3:06 PM, Tom
Cameron <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Tom.Cameron@rackspace.com" target="_blank">Tom.Cameron@rackspace.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">>I
would not call that the extreme minority.<br>
>I would say a good percentage of users are on only
getting to Juno now.<br>
<br>
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".<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
--<br>
Tom Cameron<br>
<br>
<br>
________________________________________<br>
From: Maish Saidel-Keesing <<a moz-do-not-send="true"
href="mailto:maishsk@maishsk.com">maishsk@maishsk.com</a>><br>
Sent: Monday, November 9, 2015 14:29<br>
To: Tom Cameron; Jeremy Stanley; <a moz-do-not-send="true"
href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
Subject: Re: [Openstack-operators] [openstack-dev]
[stable][all] Keeping Juno "alive" for longer.<br>
<br>
On 11/09/15 21:01, Tom Cameron wrote:<br>
> From your other thread...<br>
><br>
>> Or else you're saying you intend to fix the current
inability of our projects to skip intermediate releases
entirely during upgrades<br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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?<br>
I would not call that the extreme minority.<br>
I would say a good percentage of users are on only getting
to Juno now.<br>
><br>
> --<br>
> Tom Cameron<br>
><br>
><br>
> ________________________________________<br>
> From: Jeremy Stanley <<a moz-do-not-send="true"
href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
> Sent: Monday, November 9, 2015 12:35<br>
> To: <a moz-do-not-send="true"
href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
> Subject: Re: [Openstack-operators] [openstack-dev]
[stable][all] Keeping Juno "alive" for longer.<br>
><br>
> On 2015-11-09 17:11:35 +0000 (+0000), Tom Cameron
wrote:<br>
> [...]<br>
>> I support an LTS release strategy because it will
allow more<br>
>> adoption for more sectors by offering that
stability everyone's<br>
>> talking about. But, it shouldn't be a super-super
long support<br>
>> offering. Maybe steal some of Ubuntu's game and do
an LTS every 4<br>
>> releases or so (24 months), but then maybe
Openstack only supports<br>
>> them for 24 months time? Again, my concern is that
this is free,<br>
>> open source software and you're probably not going
to get many<br>
>> community members to volunteer to offer their
precious time fixing<br>
>> bugs in a 2-year-old codebase that have been fixed
for 18 months<br>
>> in a newer version.<br>
> [...]<br>
><br>
> Because we want people to be able upgrade their
deployments, the<br>
> problem runs deeper than just backporting some fixes to
a particular<br>
> branch for longer periods of time. Unfortunately the
original poster<br>
> cross-posted this thread to multiple mailing lists so
the discussion<br>
> has rapidly bifurcated, but I addressed this particular
topic in my<br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/078735.html"
rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-November/078735.html</a><br>
> reply.<br>
<span class="">> --<br>
> Jeremy Stanley<br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</span>--<br>
Best Regards,<br>
Maish Saidel-Keesing<br>
<div class="HOEnZb">
<div class="h5">_______________________________________________<br>
OpenStack-operators mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-operators mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Best Regards,<br>
Maish Saidel-Keesing</div>
</body>
</html>