Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Jesse Pretorius]

On 9 November 2015 at 14:42, Sean Dague  wrote:

>
> So lets figure out where the snags are. I'm pretty uninterested in
> threads that just scream LTS without a list of upgrade bugs that have
> been filed to describe why rapid upgrade isn't the right long term
> solution.


I agree with this wholeheartedly. Simpler, more reliable and more online
upgrades are the targeted solution.

As adoption of OpenStack grows, distributors are going to have to play a
much larger role in driving their own end-user concerns by committing their
own resources to make those concerns become a reality.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 05:15:18PM +1100, Tony Breeds wrote:
> Hello all,
> 
> I'll start by acknowledging that this is a big and complex issue and I
> do not claim to be across all the view points, nor do I claim to be
> particularly persuasive ;P
> 
> Having stated that, I'd like to seek constructive feedback on the idea of
> keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.

For the record this thread, conversations I've had in private and the fact
noone else has stepped up .

Juno is no more long live Kilo!

Tony.


pgpYcub1aMMVn.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Sean Dague]

On 11/09/2015 05:30 AM, Hugh Blemings wrote:
> Hiya,
> 
> On 7/11/2015 06:42, Sean Dague wrote:
>> On 11/06/2015 01:15 AM, Tony Breeds wrote:
>>> Hello all,
>>>
>>> I'll start by acknowledging that this is a big and complex issue and I
>>> do not claim to be across all the view points, nor do I claim to be
>>> particularly persuasive ;P
>>>
>>> Having stated that, I'd like to seek constructive feedback on the
>>> idea of
>>> keeping Juno around for a little longer.  During the summit I spoke to a
>>> number of operators, vendors and developers on this topic.  There was
>>> some
>>> support and some "That's crazy pants!" responses.  I clearly didn't
>>> make it
>>> around to everyone, hence this email.
>>>
>>> Acknowledging my affiliation/bias:  I work for Rackspace in the private
>>> cloud team.  We support a number of customers currently running Juno
>>> that are,
>>> for a variety of reasons, challenged by the Kilo upgrade.
>>
>> The upstream strategy has been make upgrades unexciting, and then folks
>> can move forward easily.
>>
>> I would really like to unpack what those various reasons are that people
>> are trapped. Because figuring out why they feel that way is important
>> data in what needs to be done better on upgrade support and testing.
> 
> In reading this thread and Sean's post, I wonder out loud if we're
> seeing something somewhat new to OpenStack here, but perhaps not to
> other FOSS projects.
> 
> Specifically does Kilo happen to mark a point where a much larger number
> of end users have adopted OpenStack and so we're starting to see a much
> greater number of visible and mainstream users facing the "upgrade
> difficulty question" ?
> 
> If Juno us the point where we suddenly got an order of magnitude more
> deployments, then some point later you'll see an order of magnitude more
> end users struggling with how/when to upgrade.
> 
> Really wish I could articulate this better, but perhaps the point can be
> distilled from the ramble...

Honestly, I think that every release has seen a larger number of new
installations than the release before it. The stable EOL thread is
nothing new. The promise that people will show up is nothing new. The
lack of anyone else showing up to help maintain stable is nothing new.

I do think we need to focus on the snags though. Very few upstreams
maintain LTS releases. A big piece of that is it makes upgrades harder.
It means a ton of changes are being inflicted on you all at once.
Especially if you want to get to the point of live upgrading an
installation using live migration to create 0 downtime environments.
Which means that you've got to be able to live upgrade between the
versions of libvirt / ovs across that time frame.

So lets figure out where the snags are. I'm pretty uninterested in
threads that just scream LTS without a list of upgrade bugs that have
been filed to describe why rapid upgrade isn't the right long term
solution.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Hugh Blemings]

Hiya,

On 7/11/2015 06:42, Sean Dague wrote:

On 11/06/2015 01:15 AM, Tony Breeds wrote:

Hello all,

I'll start by acknowledging that this is a big and complex issue and I
do not claim to be across all the view points, nor do I claim to be
particularly persuasive ;P

Having stated that, I'd like to seek constructive feedback on the idea of
keeping Juno around for a little longer.  During the summit I spoke to a
number of operators, vendors and developers on this topic.  There was some
support and some "That's crazy pants!" responses.  I clearly didn't make it
around to everyone, hence this email.

Acknowledging my affiliation/bias:  I work for Rackspace in the private
cloud team.  We support a number of customers currently running Juno that are,
for a variety of reasons, challenged by the Kilo upgrade.


The upstream strategy has been make upgrades unexciting, and then folks
can move forward easily.

I would really like to unpack what those various reasons are that people
are trapped. Because figuring out why they feel that way is important
data in what needs to be done better on upgrade support and testing.


In reading this thread and Sean's post, I wonder out loud if we're 
seeing something somewhat new to OpenStack here, but perhaps not to 
other FOSS projects.


Specifically does Kilo happen to mark a point where a much larger number 
of end users have adopted OpenStack and so we're starting to see a much 
greater number of visible and mainstream users facing the "upgrade 
difficulty question" ?


If Juno us the point where we suddenly got an order of magnitude more 
deployments, then some point later you'll see an order of magnitude more 
end users struggling with how/when to upgrade.


Really wish I could articulate this better, but perhaps the point can be 
distilled from the ramble...


Cheers,
Hugh




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 02:42:20PM -0500, Sean Dague wrote:

> The upstream strategy has been make upgrades unexciting, and then folks
> can move forward easily.
> 
> I would really like to unpack what those various reasons are that people
> are trapped. Because figuring out why they feel that way is important
> data in what needs to be done better on upgrade support and testing.

I wish I could give you a list of n things but I can't.  Some are internal to
our offereing and not relevant to the community.  The rest are really just the
things we already know about and we're making incremental imporvements on.

Yours Tony.


pgpsgXGdDzxbI.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 09:20:08AM -0600, Matt Riedemann wrote:

> It also extends the life and number of tests that need to be run against
> things in Tempest, which already runs several dozen jobs per change proposed
> today (since Tempest is branchless).

Okay this is something that I hadn't thought of before, and none of the people
I spoke to have mentioned.  That is somethign I dont' even have a half-formed
"answer" for.
 
> At this point stable/juno is pretty much a goner, IMO. The last few months
> of activity that I've been involved in have been dealing with requirements
> capping issues, which as we've seen you fix one issue to unwedge a project
> and with the g-r syncs we end up breaking 2 other projects, and the cycle
> never ends.

Yeah the requirements wack-a-mole or tangled-web-of-onions.  I feel like we're
always one review away from sorting it out :)
 
> This is not as problematic in stable/kilo because we've done a better job of
> isolating versions in g-r from the start, but things won't get really good
> until stable/liberty when we've got upper-constraints in action.

Also we're doing better with upgrades in newwer releases so in general things
are looking up :D
 
> So I'm optimistic that we can keep stable/kilo around and working longer
> than what we've normally done in the past, but I don't hold out much hope
> for stable/juno at this point given it's current state.
 
Yours Tony.


pgp6xs_n7vW6P.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Friday, November 06, 2015 6:15 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operat...@lists.openstack.org
> Subject: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.
> 
> Hello all,
> 
> I'll start by acknowledging that this is a big and complex issue and I do not
> claim to be across all the view points, nor do I claim to be particularly
> persuasive ;P
> 
> Having stated that, I'd like to seek constructive feedback on the idea of
> keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.

I'm not big fan of this idea, number of reasons below.
> 
> Acknowledging my affiliation/bias:  I work for Rackspace in the private cloud
> team.  We support a number of customers currently running Juno that are,
> for a variety of reasons, challenged by the Kilo upgrade.

I'm working at HPE in the Cloud Engineering team, fwiw.
> 
> Here is a summary of the main points that have come up in my
> conversations, both for and against.
> 
> Keep Juno:
>  * According to the current user survey[1] Icehouse still has the
>biggest install base in production clouds.  Juno is second, which makes
>sense. If we EOL Juno this month that means ~75% of production clouds
>will be running an EOL'd release.  Clearly many of these operators have
>support contracts from their vendor, so those operators won't be left
>completely adrift, but I believe it's the vendors that benefit from keeping
>Juno around. By working together *in the community* we'll see the best
>results.

As you say there should some support base for these releases. Unfortunately 
that has had really small reflection to upstream. It looks like these vendors 
and operators keep backporting to their own forks, but do not propose the 
backports to upstream branches, or these installations are not really 
maintained.
> 
>  * We only recently EOL'd Icehouse[2].  Sure it was well communicated, but
> we
>still have a huge Icehouse/Juno install base.
> 
> For me this is pretty compelling but for balance 
> 
> Keep the current plan and EOL Juno Real Soon Now:
>  * There is also no ignoring the elephant in the room that with HP stepping
>back from public cloud there are questions about our CI capacity, and
>keeping Juno will have an impact on that critical resource.

I leave this point open as I do not know what our plans towards infra are. 
Perhaps someone could shed some light who does know.
> 
>  * Juno (and other stable/*) resources have a non-zero impact on *every*
>project, esp. @infra and release management.  We need to ensure this
>isn't too much of a burden.  This mostly means we need enough
> trustworthy
>volunteers.

This has been the main driver for shorter support cycles so far. The group 
maintaining stable branches is small and at least I haven't seen huge increase 
on that lately. Stable branches are getting bit more attention again and some 
great work has been done to ease up the workloads, but same time we get loads 
of new features and projects in that has affect on infra (resource wise) and 
gate stability.
> 
>  * Juno is also tied up with Python 2.6 support. When
>Juno goes, so will Python 2.6 which is a happy feeling for a number of
>people, and more importantly reduces complexity in our project
>infrastructure.

I know lots of people have been waiting this, myself included.
> 
>  * Even if we keep Juno for 6 months or 1 year, that doesn't help vendors
>that are "on the hook" for multiple years of support, so for that case
>we're really only delaying the inevitable.
> 
>  * Some number of the production clouds may never migrate from $version,
> in
>which case longer support for Juno isn't going to help them.

Both very true.
> 
> 
> I'm sure these question were well discussed at the VYR summit where we
> set the EOL date for Juno, but I was new then :) What I'm asking is:
> 
> 1) Is it even possible to keep Juno alive (is the impact on the project as
>a whole acceptable)?

Based on current status I do not think so.
> 
> Assuming a positive answer:
> 
> 2) Who's going to do the work?
> - Me, who else?

This is one of the key questions.

> 3) What do we do if people don't actually do the work but we as a community
>have made a commitment?

This was done in YVR, we decided to cut the losses and EOL early.

> 4) If we keep Juno alive for $some_time, does that imply we also bump 

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Thierry Carrez]

Tony Breeds wrote:
> [...]
> 1) Is it even possible to keep Juno alive (is the impact on the project as
>a whole acceptable)?

It is *technically* possible, imho. The main cost to keep it is that the
branches get regularly broken by various other changes, and those breaks
are non-trivial to fix (we have taken steps to make branches more
resilient, but those only started to appear in stable/liberty). The
issues sometimes propagate (through upgrade testing) to master, at which
point it becomes everyone's problem to fix it. The burden ends up
falling on the usual gate fixers heroes, a rare resource we need to protect.

So it's easy to say "we should keep the branch since so many people
still use it", unless we have significantly more people working on (and
capable of) fixing it when it's broken, the impact on the project is
just not acceptable.

It's not the first time this has been suggested, and every time our
answer was "push more resources in fixing existing stable branches and
we might reconsider it". We got promised lots of support. But I don't
think we have yet seen real change in that area (I still see the same
usual suspects fixing stable gates), and things can still barely keep
afloat with our current end-of-life policy...

Stable branches also come with security support, so keeping more
branches opened mechanically adds to the work of the Vulnerability
Management Team, another rare resource.

There are other hidden costs on the infrastructure side (we can't get
rid of a number of things that we have moved away from until the old
branch still needing those things is around), but I'll let someone
closer to the metal answer that one.

> Assuming a positive answer:
> 
> 2) Who's going to do the work?
> - Me, who else?
> 3) What do we do if people don't actually do the work but we as a community
>have made a commitment?

In the past, that generally meant people opposed to the idea of
extending support periods having to stand up for the community promise
and fix the mess in the end.

PS: stable gates are currently broken for horizon/juno, trove/kilo, and
neutron-lbaas/liberty.

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Matt Riedemann]

On 11/6/2015 4:43 AM, Thierry Carrez wrote:

Tony Breeds wrote:

[...]
1) Is it even possible to keep Juno alive (is the impact on the project as
a whole acceptable)?


It is *technically* possible, imho. The main cost to keep it is that the
branches get regularly broken by various other changes, and those breaks
are non-trivial to fix (we have taken steps to make branches more
resilient, but those only started to appear in stable/liberty). The
issues sometimes propagate (through upgrade testing) to master, at which
point it becomes everyone's problem to fix it. The burden ends up
falling on the usual gate fixers heroes, a rare resource we need to protect.

So it's easy to say "we should keep the branch since so many people
still use it", unless we have significantly more people working on (and
capable of) fixing it when it's broken, the impact on the project is
just not acceptable.

It's not the first time this has been suggested, and every time our
answer was "push more resources in fixing existing stable branches and
we might reconsider it". We got promised lots of support. But I don't
think we have yet seen real change in that area (I still see the same
usual suspects fixing stable gates), and things can still barely keep
afloat with our current end-of-life policy...

Stable branches also come with security support, so keeping more
branches opened mechanically adds to the work of the Vulnerability
Management Team, another rare resource.

There are other hidden costs on the infrastructure side (we can't get
rid of a number of things that we have moved away from until the old
branch still needing those things is around), but I'll let someone
closer to the metal answer that one.


Assuming a positive answer:

2) Who's going to do the work?
 - Me, who else?
3) What do we do if people don't actually do the work but we as a community
have made a commitment?


In the past, that generally meant people opposed to the idea of
extending support periods having to stand up for the community promise
and fix the mess in the end.

PS: stable gates are currently broken for horizon/juno, trove/kilo, and
neutron-lbaas/liberty.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



In general I'm in favor of trying to keep the stable branches available 
as long as possible because of (1) lots of production deployments not 
upgrading as fast as we (the dev team) assume they are and (2) 
backporting security fixes upstream is much nicer as a community than 
doing it out of tree when you support 5+ years of releases.


Having said that, the downside points above are very valid, i.e. not 
enough resources to help, we want to drop py26, things get wedged easily 
and there aren't people around to monitor or fix it, or understand how 
all of the stable branch + infra + QA stuff fits together.


It also extends the life and number of tests that need to be run against 
things in Tempest, which already runs several dozen jobs per change 
proposed today (since Tempest is branchless).


At this point stable/juno is pretty much a goner, IMO. The last few 
months of activity that I've been involved in have been dealing with 
requirements capping issues, which as we've seen you fix one issue to 
unwedge a project and with the g-r syncs we end up breaking 2 other 
projects, and the cycle never ends.


This is not as problematic in stable/kilo because we've done a better 
job of isolating versions in g-r from the start, but things won't get 
really good until stable/liberty when we've got upper-constraints in action.


So I'm optimistic that we can keep stable/kilo around and working longer 
than what we've normally done in the past, but I don't hold out much 
hope for stable/juno at this point given it's current state.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Matt Riedemann]

On 11/6/2015 9:20 AM, Matt Riedemann wrote:



On 11/6/2015 4:43 AM, Thierry Carrez wrote:

Tony Breeds wrote:

[...]
1) Is it even possible to keep Juno alive (is the impact on the
project as
a whole acceptable)?


It is *technically* possible, imho. The main cost to keep it is that the
branches get regularly broken by various other changes, and those breaks
are non-trivial to fix (we have taken steps to make branches more
resilient, but those only started to appear in stable/liberty). The
issues sometimes propagate (through upgrade testing) to master, at which
point it becomes everyone's problem to fix it. The burden ends up
falling on the usual gate fixers heroes, a rare resource we need to
protect.

So it's easy to say "we should keep the branch since so many people
still use it", unless we have significantly more people working on (and
capable of) fixing it when it's broken, the impact on the project is
just not acceptable.

It's not the first time this has been suggested, and every time our
answer was "push more resources in fixing existing stable branches and
we might reconsider it". We got promised lots of support. But I don't
think we have yet seen real change in that area (I still see the same
usual suspects fixing stable gates), and things can still barely keep
afloat with our current end-of-life policy...

Stable branches also come with security support, so keeping more
branches opened mechanically adds to the work of the Vulnerability
Management Team, another rare resource.

There are other hidden costs on the infrastructure side (we can't get
rid of a number of things that we have moved away from until the old
branch still needing those things is around), but I'll let someone
closer to the metal answer that one.


Assuming a positive answer:

2) Who's going to do the work?
 - Me, who else?
3) What do we do if people don't actually do the work but we as a
community
have made a commitment?


In the past, that generally meant people opposed to the idea of
extending support periods having to stand up for the community promise
and fix the mess in the end.

PS: stable gates are currently broken for horizon/juno, trove/kilo, and
neutron-lbaas/liberty.



__

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



In general I'm in favor of trying to keep the stable branches available
as long as possible because of (1) lots of production deployments not
upgrading as fast as we (the dev team) assume they are and (2)
backporting security fixes upstream is much nicer as a community than
doing it out of tree when you support 5+ years of releases.

Having said that, the downside points above are very valid, i.e. not
enough resources to help, we want to drop py26, things get wedged easily
and there aren't people around to monitor or fix it, or understand how
all of the stable branch + infra + QA stuff fits together.

It also extends the life and number of tests that need to be run against
things in Tempest, which already runs several dozen jobs per change
proposed today (since Tempest is branchless).

At this point stable/juno is pretty much a goner, IMO. The last few
months of activity that I've been involved in have been dealing with
requirements capping issues, which as we've seen you fix one issue to
unwedge a project and with the g-r syncs we end up breaking 2 other
projects, and the cycle never ends.

This is not as problematic in stable/kilo because we've done a better
job of isolating versions in g-r from the start, but things won't get
really good until stable/liberty when we've got upper-constraints in
action.

So I'm optimistic that we can keep stable/kilo around and working longer
than what we've normally done in the past, but I don't hold out much
hope for stable/juno at this point given it's current state.



Didn't mean to break the cross-list chain.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Sean Dague]

On 11/06/2015 01:15 AM, Tony Breeds wrote:
> Hello all,
> 
> I'll start by acknowledging that this is a big and complex issue and I
> do not claim to be across all the view points, nor do I claim to be
> particularly persuasive ;P
> 
> Having stated that, I'd like to seek constructive feedback on the idea of
> keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.
> 
> Acknowledging my affiliation/bias:  I work for Rackspace in the private
> cloud team.  We support a number of customers currently running Juno that are,
> for a variety of reasons, challenged by the Kilo upgrade.

The upstream strategy has been make upgrades unexciting, and then folks
can move forward easily.

I would really like to unpack what those various reasons are that people
are trapped. Because figuring out why they feel that way is important
data in what needs to be done better on upgrade support and testing.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

Hello all,

I'll start by acknowledging that this is a big and complex issue and I
do not claim to be across all the view points, nor do I claim to be
particularly persuasive ;P

Having stated that, I'd like to seek constructive feedback on the idea of
keeping Juno around for a little longer.  During the summit I spoke to a
number of operators, vendors and developers on this topic.  There was some
support and some "That's crazy pants!" responses.  I clearly didn't make it
around to everyone, hence this email.

Acknowledging my affiliation/bias:  I work for Rackspace in the private
cloud team.  We support a number of customers currently running Juno that are,
for a variety of reasons, challenged by the Kilo upgrade.

Here is a summary of the main points that have come up in my conversations,
both for and against.

Keep Juno:
 * According to the current user survey[1] Icehouse still has the
   biggest install base in production clouds.  Juno is second, which makes
   sense. If we EOL Juno this month that means ~75% of production clouds
   will be running an EOL'd release.  Clearly many of these operators have
   support contracts from their vendor, so those operators won't be left 
   completely adrift, but I believe it's the vendors that benefit from keeping
   Juno around. By working together *in the community* we'll see the best
   results.

 * We only recently EOL'd Icehouse[2].  Sure it was well communicated, but we
   still have a huge Icehouse/Juno install base.

For me this is pretty compelling but for balance  

Keep the current plan and EOL Juno Real Soon Now:
 * There is also no ignoring the elephant in the room that with HP stepping
   back from public cloud there are questions about our CI capacity, and
   keeping Juno will have an impact on that critical resource.

 * Juno (and other stable/*) resources have a non-zero impact on *every*
   project, esp. @infra and release management.  We need to ensure this
   isn't too much of a burden.  This mostly means we need enough trustworthy
   volunteers.

 * Juno is also tied up with Python 2.6 support. When
   Juno goes, so will Python 2.6 which is a happy feeling for a number of
   people, and more importantly reduces complexity in our project
   infrastructure.

 * Even if we keep Juno for 6 months or 1 year, that doesn't help vendors
   that are "on the hook" for multiple years of support, so for that case
   we're really only delaying the inevitable.

 * Some number of the production clouds may never migrate from $version, in
   which case longer support for Juno isn't going to help them.


I'm sure these question were well discussed at the VYR summit where we set
the EOL date for Juno, but I was new then :) What I'm asking is:

1) Is it even possible to keep Juno alive (is the impact on the project as
   a whole acceptable)?

Assuming a positive answer:

2) Who's going to do the work?
- Me, who else?
3) What do we do if people don't actually do the work but we as a community
   have made a commitment?
4) If we keep Juno alive for $some_time, does that imply we also bump the
   life cycle on Kilo and liberty and Mitaka etc?

Yours Tony.

[1] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
(page 20)
[2] http://git.openstack.org/cgit/openstack/nova/tag/?h=icehouse-eol



pgpzQJvMDmBfU.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev