Re: [Openstack-operators] [openstack-dev] [LTS] Upstream LTS Releases

Well, moving this discussion is easy. All that takes is everyone posting responses to the openstack-...@lists.openstack.org mailing list instead of dev and ops lists. I've cc'ed all here. I've also added [LTS] to the subject (sorry to break all the threaders). So that the sig list knows what

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On 14 Nov 2017, at 16:08, Davanum Srinivas wrote: > On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote: >> >> >> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: >> >>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: The pressure for #2 comes from

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

I can think of a few ideas, though some sound painful on paper Not really recommending anything, just thinking out loud... One idea is that at the root of chaos monkey. If something is hard, do it frequently. If upgrading is hard, we need to be doing it constantly so the pain gets largely

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 4:10 PM, Rochelle Grober wrote: > Folks, > > This discussion and the people interested in it seem like a perfect > application of the SIG process. By turning LTS into a SIG, everyone can > discuss the issues on the SIG mailing list and the

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: >>> The pressure for #2 comes from the inability to skip upgrades and the fact >>> that upgrades

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

For those wondering why operators can’t always upgrade sooner, I can add a little bit of color: In our clouds, we have a couple vendors (one network plugin, one cinder driver) and those vendors typically are 1-3 releases behind ‘cutting edge’. By the time they support the version we want to

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: >> The pressure for #2 comes from the inability to skip upgrades and the fact >> that upgrades are hugely time consuming still. >> >> If you want to reduce the push for

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: > The pressure for #2 comes from the inability to skip upgrades and the fact > that upgrades are hugely time consuming still. > > If you want to reduce the push for number #2 and help developers get their > wish of getting

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

The pressure for #2 comes from the inability to skip upgrades and the fact that upgrades are hugely time consuming still. If you want to reduce the push for number #2 and help developers get their wish of getting features into users hands sooner, the path to upgrade really needs to be much

Re: [Openstack-operators] [openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur wrote: > Hi folks! > > This was raised several times, now I want to bring it to the wider audience. > We're planning [1] to deprecate classic drivers in Queens and remove them in > Rocky. It was pointed at the Forum that we'd

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

Folks, This discussion and the people interested in it seem like a perfect application of the SIG process. By turning LTS into a SIG, everyone can discuss the issues on the SIG mailing list and the discussion shouldn't end up split. If it turns into a project, great. If a solution is found

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On 11/14/2017 06:21 PM, Erik McCormick wrote: On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite wrote: Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite wrote: > Hi all - please note this conversation has been split variously across > -dev and -operators. > > One small observation from the discussion so far is that it seems as > though there are two issues being

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

Blair, Please add #2 as a line proposal in: https://etherpad.openstack.org/p/LTS-proposal So far it's focused on #1 Thanks, Dims On Wed, Nov 15, 2017 at 3:30 AM, Blair Bethwaite wrote: > Hi all - please note this conversation has been split variously across > -dev

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as though there are two issues being discussed under the one banner: 1) maintain old releases for longer 2) do stable releases less

Re: [Openstack-operators] [openstack-dev] LTS pragmatic example

Flavio, Saverio, Agree, that review may be a good example of what could be done. More info below. Saverio said - "with the old Stable Release thinking this patch would not be accepted on old stable branches." My response - "Those branches are still under stable policy. That has not changed just

Re: [Openstack-operators] [openstack-dev] LTS pragmatic example

On 14/11/17 22:33 +1100, Davanum Srinivas wrote: Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current

[Openstack-operators] [ironic] automatic migration from classic drivers to hardware types?

Hi folks! This was raised several times, now I want to bring it to the wider audience. We're planning [1] to deprecate classic drivers in Queens and remove them in Rocky. It was pointed at the Forum that we'd better provide an automatic migration. I'd like to hear your opinion on the

Re: [Openstack-operators] [External] OpenStack-create volume backup through heat template

Hi Team, Can we create volume backup through heat template? Thanks, Bhumika -Original Message- From: openstack-operators-requ...@lists.openstack.org [mailto:openstack-operators-requ...@lists.openstack.org] Sent: Tuesday, November 14, 2017 5:30 PM To:

Re: [Openstack-operators] [openstack-dev] LTS pragmatic example

Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current teams can't scale, they should not have to and it's

[Openstack-operators] LTS pragmatic example

Hello, here an example of a trivial patch that is important for people that do operations, and they have to troubleshoot stuff. with the old Stable Release thinking this patch would not be accepted on old stable branches. Let's see if this gets accepted back to stable/newton