ail.com]
> Sent: Tuesday, November 14, 2017 4:08 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: openstack-oper.
> Subject: Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases
>
> On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote:
>
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 stand
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.
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 projec
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 the inability to skip upgrades and
Stack Development Mailing List (not for usage questions)
Cc: openstack-oper.
Subject: Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases
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 a
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 discussion shouldn't end
> up
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 are hugely time consuming still.
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 the inability to skip upgrades and the fact
>>> that upgrades are hugely time consuming still.
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 are hugely time consuming still.
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 go
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 number #2 and help deve
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 features into users
-operators] 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 t
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
though there are two issues be
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 discussed under the one banner:
> 1)
On 11/10/2017 11:51 PM, John Dickinson wrote:
On 7 Nov 2017, at 15:28, 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 mainta
On Fri, Nov 10, 2017 at 2:51 PM, 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
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 isn't deleted aft
On 7 Nov 2017, at 15:28, 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 period of time (LTS).
>
> There was a
20 matches
Mail list logo