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

On 2017-11-15 00:37:26 + (+), Fox, Kevin M wrote: [...] > 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 eliminated. One idea would > be to discourage the use of

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

John Dickinson wrote: > What I heard from ops in the room is that they want (to start) one > release a year who's branch isn't deleted after a year. What if that's > exactly what we did? I propose that OpenStack only do one release a year > instead of two. We still keep N-2 stable releases around.

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

I suggested by Rocky, I moved the discussion to the -sigs list by posting my promised summary of the session at: http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000148.html Please continue the discussion there, to avoid the cross-posting. If you haven't already, please

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

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 discussion shouldn't end > up split. If it turns into a

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] 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] Upstream LTS Releases

+1 to " If there are no contributors for an LTS release, there will be no LTS release. If there *are* contributors, then we'll find a way to make some sort of LTS model work within the other constraints we have." +1 to let's get some folks who are interested a place to collaborate and talk to

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

Excerpts from Clint Byrum's message of 2017-11-11 08:41:15 -0800: > Excerpts from Doug Hellmann's message of 2017-11-10 13:11:45 -0500: > > Excerpts from Clint Byrum's message of 2017-11-08 23:15:15 -0800: > > > Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800: > > > > On Tue,

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

On 11/08/2017 05:27 PM, Samuel Cassiba wrote: > ie. deployment-focused development > teams already under a crunch as contributor count continues to decline > in favor of other projects inside and out of OpenStack. Did you even think that one of the reason for such a decline, is that OpenStack is

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

Excerpts from Doug Hellmann's message of 2017-11-10 13:11:45 -0500: > Excerpts from Clint Byrum's message of 2017-11-08 23:15:15 -0800: > > Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800: > > > On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick > > >

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

I missed this session but the discussion strikes a chord as this is something I've been saying on my user survey every 6 months. On 11 November 2017 at 09:51, John Dickinson wrote: > What I heard from ops in the room is that they want (to start) one release a > year who's branch

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

Excerpts from Clint Byrum's message of 2017-11-08 23:15:15 -0800: > Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800: > > On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick > > wrote: > > > Hello Ops folks, > > > > > > This morning at the Sydney Summit

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

On Thu, Nov 09, 2017 at 04:34:24PM +, Jeremy Stanley wrote: :On 2017-11-08 23:15:15 -0800 (-0800), Clint Byrum wrote: :[...] :> The biggest challenge will be ensuring that the skip-level upgrades :> work. The current grenade based upgrade jobs are already quite a bear to :> keep working IIRC.

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

On 2017-11-08 23:15:15 -0800 (-0800), Clint Byrum wrote: [...] > The biggest challenge will be ensuring that the skip-level upgrades > work. The current grenade based upgrade jobs are already quite a bear to > keep working IIRC. I've not seen if chef or any of the deployment projects > test

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

Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800: > On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick > wrote: > > Hello Ops folks, > > > > This morning at the Sydney Summit we had a very well attended and very > > productive session about how to go

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

On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick wrote: > Hello Ops folks, > > This morning at the Sydney Summit we had a very well attended and very > productive session about how to go about keeping a selection of past > releases available and maintained for a longer

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

On Nov 8, 2017 1:52 PM, "James E. Blair" wrote: Erik McCormick writes: > On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair wrote: >> Erik McCormick writes: >> >>> The concept, in general, is to

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

Erik McCormick wrote: > This morning at the Sydney Summit we had a very well attended and very > productive session about how to go about keeping a selection of past > releases available and maintained for a longer period of time (LTS). > > There was agreement in the room that this could be

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

On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair wrote: > Erik McCormick writes: > >> The concept, in general, is to create a new set of cores from these >> groups, and use 3rd party CI to validate patches. There are lots of >> details to be worked