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.
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 subscrib
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
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 e
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
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 less
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 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)
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 and -operators.
>
> One small
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 frequent
+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
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, No
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 m
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
> > > wrote:
> > > > Hello Ops folks
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
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 we had a very well attended an
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. I
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 upgrade
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 about keeping a selection of pas
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 period of time (LTS).
>
> Ther
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 create a new set of cores from these
>>> groups, and use 3rd party CI to validate patches. There are l
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 accomp
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 out yet, but our amazing UC (User Committee) will
32 matches
Mail list logo
