Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Mark Baker]

Certainly the aim is to support upgrades between LTS releases.
Getting a meaningful keynote slot at an OpenStack summit is more of a
challenge.

On 6 Nov 2015 9:27 pm, "Jonathan Proulx"  wrote:
>
> On Fri, Nov 06, 2015 at 05:28:13PM +, Mark Baker wrote:
> :Worth mentioning that OpenStack releases that come out at the same time
as
> :Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) are
> :supported for 5 years by Canonical so are already kind of an LTS. Support
> :in this context means patches, updates and commercial support (for a
fee).
> :For paying customers 3 years of patches, updates and commercial support
for
> :April releases, (Kilo, O, Q etc..) is also available.
>
> 
> And Canonical will support a live upgarde directly from Essex to
> Icehouse and Icehouse to Mitaka?
>
> I'd love to see Shuttleworth do that that as a live keynote, but only
> on a system with at least hundres on nodes and many VMs...
> 
>
> That's where LTS falls down conceptually we're struggling to make
> single release upgrades work at this point.
>
> I do agree LTS for release would be great but honestly OpenStack isn't
> Mature enough for that yet.
>
> -Jon
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [logs] Neutron not logging user information on wsgi requests by default

[Kris G. Lindgren]

Hello all,

I noticed the otherday that in our Openstack install (Kilo) Neutron seems to be 
the only project that was not logging the username/tenant information on every 
wsgi request.  Nova/Glance/heat all log a username and/or project on each 
request.  Our wsgi logs from neutron look like the following:

2015-11-05 13:45:24.302 14549 INFO neutron.wsgi 
[req-ab633261-da6d-4ac7-8a35-5d321a8b4a8f ] 10.224.48.132 - - [05/Nov/2015 
13:45:24]
"GET /v2.0/networks.json?id=2d5fe344-4e98-4ccc-8c91-b8064d17c64c HTTP/1.1" 200 
655 0.027550

I did a fair amount of digging and it seems that devstack is by default 
overriding the context log format for neutron to add the username/tenant 
information into the logs.  However, there is active work to remove this 
override from devstack[1].  However, using the devstack way I was able to true 
up our neutron wsgi logs to be inline with what other services are providing.

If you add:
logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s %(name)s 
[%(request_id)s %(user_name)s %(project_name)s] %(instance)s%(message)s

To the [DEFAULT] section of neutron.conf and restart neutron-server.  You will 
now get log output like the following:

 2015-11-05 18:07:31.033 INFO neutron.wsgi 
[req-ebf1d3c9-b556-48a7-b1fa-475dd9df0bf7  ] 10.224.48.132 - - [05/Nov/2015 18:07:31]
"GET /v2.0/networks.json?id=55e1b92a-a2a3-4d64-a2d8-4b0bee46f3bf HTTP/1.1" 200 
617 0.035515

So go forth, check your logs, and before you need to use your logs to debug who 
did what,when, and where.  Get the information that you need added to the wsgi 
logs.  if you are not seeing wsgi logs for your projects trying enabling 
verbose=true in the [DEFAULT] section as well.

Adding [logs] tag since it would be nice to have all projects logging to a 
standard wsgi format out of the gate.

[1] - https://review.openstack.org/#/c/172508/2/lib/neutron-legacy
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Clint Byrum]

Excerpts from Tony Breeds's message of 2015-11-05 22:15:18 -0800:
> 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
> 

 In the future, also consider not making it even more complex by
cross posting!

Indeed, it is not cut and dry.

> 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.
> 

While I wish everybody would get on the Continuous Delivery train, I
understand that it's still comforting to many to use stable releases with
the hope that this will somehow keep them more available (it won't, there
are more scalability and reslience bugs fixed than "big risky changes"
landed by quite a large factor, in trunk) or that it will be less change
(it isn't, you can eat the elephant one spoon-full at a time, or prepare
a feast every 6 months).

Until we all embrace the chaos-drip in favor of the chaos-deluge, we
have to keep supporting stable releases.

> 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.
> 

Wow, yeah, I had not seen these numbers yet. It sounds to me like the
number of operators who can keep up with the 6 month cadence is very low,
and LTS cycles need to be considered.

> 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)?
> 

Sure, but...

> Assuming a positive answer:
> 
> 2) Who's going to do the work?
> - Me, who else?

That's really the rub. Historically barely anybody has maintained the
stable branches, though lately that has gotten a bit better.

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

There's certainly an argument to be made for downstream entities to take
this over if we, upstream, don't want it.

> 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?
> 

Probably. Doesn't seem like this problem can go away without making
concessions for longer term support though. One concession might be that
6 months is too short, and extend the cycle out. But that would have
gigantic ripple effects.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Donald Talton]

I like the idea of LTS releases. 

Speaking to my own deployments, there are many new features we are not 
interested in, and wouldn't be, until we can get organizational (cultural) 
change in place, or see stability and scalability. 

We can't rely on, or expect, that orgs will move to the CI/CD model for infra, 
when they aren't even ready to do that for their own apps. It's still a new 
"paradigm" for many of us. CI/CD requires a considerable engineering effort, 
and given that the decision to "switch" to OpenStack is often driven by 
cost-savings over enterprise virtualization, adding those costs back in via 
engineering salaries doesn't make fiscal sense.

My big argument is that if Icehouse/Juno works and is stable, and I don't need 
newer features from subsequent releases, why would I expend the effort until 
such a time that I do want those features? Thankfully there are vendors that 
understand this. Keeping up with the release cycle just for the sake of keeping 
up with the release cycle is exhausting.

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com] 
Sent: Thursday, November 05, 2015 11:15 PM
To: OpenStack Development Mailing List
Cc: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] [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.

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


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

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

[Jesse Keating]

We (Blue Box, an IBM company) do have a lot of installs on Juno, however
we'll be aggressively moving to Kilo, so we are not interested in keeping
Juno alive.


- jlk

On Fri, Nov 6, 2015 at 9:37 AM, Dan Smith  wrote:

> > Worth mentioning that OpenStack releases that come out at the same time
> > as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
> > are supported for 5 years by Canonical so are already kind of an LTS.
> > Support in this context means patches, updates and commercial support
> > (for a fee).
> > For paying customers 3 years of patches, updates and commercial support
> > for April releases, (Kilo, O, Q etc..) is also available.
>
> Yeah. IMHO, this is what you pay your vendor for. I don't think upstream
> maintaining an older release for so long is a good use of people or CI
> resources, especially given how hard it can be for us to keep even
> recent stable releases working and maintained.
>
> --Dan
>
> ___
> 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

Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Erik McCormick]

On Fri, Nov 6, 2015 at 12:28 PM, Mark Baker  wrote:
> Worth mentioning that OpenStack releases that come out at the same time as
> Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) are
> supported for 5 years by Canonical so are already kind of an LTS. Support in
> this context means patches, updates and commercial support (for a fee).
> For paying customers 3 years of patches, updates and commercial support for
> April releases, (Kilo, O, Q etc..) is also available.
>

Does that mean that you are actually backporting and gate testing
patches downstream that aren't being done upstream? I somehow doubt
it, but if so, then it would be great if you could lead some sort of
initiative to push those patches back upstream.


-Erik

>
>
> Best Regards
>
>
> Mark Baker
>
> On Fri, Nov 6, 2015 at 5:03 PM, James King  wrote:
>>
>> +1 for some sort of LTS release system.
>>
>> Telcos and risk-averse organizations working with sensitive data might not
>> be able to upgrade nearly as fast as the releases keep coming out. From the
>> summit in Japan it sounds like companies running some fairly critical public
>> infrastructure on Openstack aren’t going to be upgrading to Kilo any time
>> soon.
>>
>> Public clouds might even benefit from this. I know we (Dreamcompute) are
>> working towards tracking the upstream releases closer… but it’s not feasible
>> for everyone.
>>
>> I’m not sure whether the resources exist to do this but it’d be a nice to
>> have, imho.
>>
>> > On Nov 6, 2015, at 11:47 AM, Donald Talton 
>> > wrote:
>> >
>> > I like the idea of LTS releases.
>> >
>> > Speaking to my own deployments, there are many new features we are not
>> > interested in, and wouldn't be, until we can get organizational (cultural)
>> > change in place, or see stability and scalability.
>> >
>> > We can't rely on, or expect, that orgs will move to the CI/CD model for
>> > infra, when they aren't even ready to do that for their own apps. It's 
>> > still
>> > a new "paradigm" for many of us. CI/CD requires a considerable engineering
>> > effort, and given that the decision to "switch" to OpenStack is often 
>> > driven
>> > by cost-savings over enterprise virtualization, adding those costs back in
>> > via engineering salaries doesn't make fiscal sense.
>> >
>> > My big argument is that if Icehouse/Juno works and is stable, and I
>> > don't need newer features from subsequent releases, why would I expend the
>> > effort until such a time that I do want those features? Thankfully there 
>> > are
>> > vendors that understand this. Keeping up with the release cycle just for 
>> > the
>> > sake of keeping up with the release cycle is exhausting.
>> >
>> > -Original Message-
>> > From: Tony Breeds [mailto:t...@bakeyournoodle.com]
>> > Sent: Thursday, November 05, 2015 11:15 PM
>> > To: OpenStack Development Mailing List
>> > Cc: openstack-operators@lists.openstack.org
>> > Subject: [Openstack-operators] [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.
>> >
>> > 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 

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

[matt]

backporting patches isn't too terribly hard to be honest.  you could
probably hire a consultant to do it if need be.  mirantis would probably
quote you a price.

On Fri, Nov 6, 2015 at 3:10 PM, Fox, Kevin M  wrote:

> Kind of related, as an op, we see a lot of 3rd party repositories that
> recently only supported rhel5 move to finally supporting rhel6 because
> rhel7 came out and rhel5 went to long term support contract only. This
> caused us to have to support rhel5 way longer then we would have liked.
> Now, we're stuck at 6 instead of 7. :/
>
> Some number of users will stick with juno until it is EOL and then move.
> Sometimes its because its a desire to not make a change. Sometimes its
> considered a good thing by the ops that they finally have a "good enough"
> excuse (EOL) to move forward "finally" (sigh of relief). :)
>
> Thanks,
> Kevin
>
> --
> *From:* Jesse Keating [j...@bluebox.net]
> *Sent:* Friday, November 06, 2015 10:14 AM
> *To:* Dan Smith
> *Cc:* OpenStack Development Mailing List (not for usage questions);
> openstack-operators@lists.openstack.org
> *Subject:* Re: [Openstack-operators] [openstack-dev] [stable][all]
> Keeping Juno "alive" for longer.
>
> We (Blue Box, an IBM company) do have a lot of installs on Juno, however
> we'll be aggressively moving to Kilo, so we are not interested in keeping
> Juno alive.
>
>
> - jlk
>
> On Fri, Nov 6, 2015 at 9:37 AM, Dan Smith  wrote:
>
>> > Worth mentioning that OpenStack releases that come out at the same time
>> > as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
>> > are supported for 5 years by Canonical so are already kind of an LTS.
>> > Support in this context means patches, updates and commercial support
>> > (for a fee).
>> > For paying customers 3 years of patches, updates and commercial support
>> > for April releases, (Kilo, O, Q etc..) is also available.
>>
>> Yeah. IMHO, this is what you pay your vendor for. I don't think upstream
>> maintaining an older release for so long is a good use of people or CI
>> resources, especially given how hard it can be for us to keep even
>> recent stable releases working and maintained.
>>
>> --Dan
>>
>> ___
>> 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
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Fox, Kevin M]

Kind of related, as an op, we see a lot of 3rd party repositories that recently 
only supported rhel5 move to finally supporting rhel6 because rhel7 came out 
and rhel5 went to long term support contract only. This caused us to have to 
support rhel5 way longer then we would have liked. Now, we're stuck at 6 
instead of 7. :/

Some number of users will stick with juno until it is EOL and then move. 
Sometimes its because its a desire to not make a change. Sometimes its 
considered a good thing by the ops that they finally have a "good enough" 
excuse (EOL) to move forward "finally" (sigh of relief). :)

Thanks,
Kevin


From: Jesse Keating [j...@bluebox.net]
Sent: Friday, November 06, 2015 10:14 AM
To: Dan Smith
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [stable][all] Keeping Juno 
"alive" for longer.

We (Blue Box, an IBM company) do have a lot of installs on Juno, however we'll 
be aggressively moving to Kilo, so we are not interested in keeping Juno alive.


- jlk

On Fri, Nov 6, 2015 at 9:37 AM, Dan Smith 
> wrote:
> Worth mentioning that OpenStack releases that come out at the same time
> as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
> are supported for 5 years by Canonical so are already kind of an LTS.
> Support in this context means patches, updates and commercial support
> (for a fee).
> For paying customers 3 years of patches, updates and commercial support
> for April releases, (Kilo, O, Q etc..) is also available.

Yeah. IMHO, this is what you pay your vendor for. I don't think upstream
maintaining an older release for so long is a good use of people or CI
resources, especially given how hard it can be for us to keep even
recent stable releases working and maintained.

--Dan

___
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

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

[Jesse Keating]

I think your biggest struggle will be with "where to test this", because I
doubt upstream infra want to keep running gerrit and zuul and jenkins for
the juno branches.


- jlk

On Fri, Nov 6, 2015 at 12:32 PM, Donald Talton 
wrote:

> I agree, but to use your argument: how hard would it be to setup a small
> group to do this for the community? I’m sure there would be a few people
> interested in maintaining it…
>
>
>
> *From:* matt [mailto:m...@nycresistor.com]
> *Sent:* Friday, November 06, 2015 1:18 PM
> *To:* Fox, Kevin M
> *Cc:* Jesse Keating; OpenStack Development Mailing List (not for usage
> questions); openstack-operators@lists.openstack.org
>
> *Subject:* Re: [Openstack-operators] [openstack-dev] [stable][all]
> Keeping Juno "alive" for longer.
>
>
>
> backporting patches isn't too terribly hard to be honest.  you could
> probably hire a consultant to do it if need be.  mirantis would probably
> quote you a price.
>
>
>
> On Fri, Nov 6, 2015 at 3:10 PM, Fox, Kevin M  wrote:
>
> Kind of related, as an op, we see a lot of 3rd party repositories that
> recently only supported rhel5 move to finally supporting rhel6 because
> rhel7 came out and rhel5 went to long term support contract only. This
> caused us to have to support rhel5 way longer then we would have liked.
> Now, we're stuck at 6 instead of 7. :/
>
> Some number of users will stick with juno until it is EOL and then move.
> Sometimes its because its a desire to not make a change. Sometimes its
> considered a good thing by the ops that they finally have a "good enough"
> excuse (EOL) to move forward "finally" (sigh of relief). :)
>
> Thanks,
> Kevin
> --
>
> *From:* Jesse Keating [j...@bluebox.net]
> *Sent:* Friday, November 06, 2015 10:14 AM
> *To:* Dan Smith
> *Cc:* OpenStack Development Mailing List (not for usage questions);
> openstack-operators@lists.openstack.org
> *Subject:* Re: [Openstack-operators] [openstack-dev] [stable][all]
> Keeping Juno "alive" for longer.
>
> We (Blue Box, an IBM company) do have a lot of installs on Juno, however
> we'll be aggressively moving to Kilo, so we are not interested in keeping
> Juno alive.
>
>
>
>
> - jlk
>
>
>
> On Fri, Nov 6, 2015 at 9:37 AM, Dan Smith  wrote:
>
> > Worth mentioning that OpenStack releases that come out at the same time
> > as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
> > are supported for 5 years by Canonical so are already kind of an LTS.
> > Support in this context means patches, updates and commercial support
> > (for a fee).
> > For paying customers 3 years of patches, updates and commercial support
> > for April releases, (Kilo, O, Q etc..) is also available.
>
> Yeah. IMHO, this is what you pay your vendor for. I don't think upstream
> maintaining an older release for so long is a good use of people or CI
> resources, especially given how hard it can be for us to keep even
> recent stable releases working and maintained.
>
> --Dan
>
>
> ___
> 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
>
>
>
> 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