On 05/02/14 11:39, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-02-04 16:14:09 -0800:
On 03/02/14 17:09, Clint Byrum wrote:
UpdatePolicy in cfn is a single string, and causes very generic rolling
Huh?
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribu
On 04/02/14 20:34, Robert Collins wrote:
On 5 February 2014 13:14, Zane Bitter wrote:
That's not a great example, because one DB server depends on the other,
forcing them into updating serially anyway.
I have to say that even in general, this whole idea about applying update
policies to non-
Excerpts from Steven Dake's message of 2014-02-05 07:35:37 -0800:
> On 02/04/2014 06:34 PM, Robert Collins wrote:
> > On 5 February 2014 13:14, Zane Bitter wrote:
> >
> >
> >> That's not a great example, because one DB server depends on the other,
> >> forcing them into updating serially anyway.
>
Excerpts from Zane Bitter's message of 2014-02-04 16:14:09 -0800:
> On 03/02/14 17:09, Clint Byrum wrote:
> > Excerpts from Thomas Herve's message of 2014-02-03 12:46:05 -0800:
> >>> So, I wrote the original rolling updates spec about a year ago, and the
> >>> time has come to get serious about imp
On 02/04/2014 06:34 PM, Robert Collins wrote:
On 5 February 2014 13:14, Zane Bitter wrote:
That's not a great example, because one DB server depends on the other,
forcing them into updating serially anyway.
I have to say that even in general, this whole idea about applying update
policies to
First, I don't think RollingUpdatePattern and CanaryUpdatePattern should be 2
different entities. The second just looks like a parametrization of the first
(growth_factor=1?).
Perhaps they can just be one. Until I find parameters which would need
to mean something different, I'll just use Upda
On Tue, Feb 4, 2014 at 7:34 PM, Robert Collins wrote:
> On 5 February 2014 13:14, Zane Bitter wrote:
>
>
> > That's not a great example, because one DB server depends on the other,
> > forcing them into updating serially anyway.
> >
> > I have to say that even in general, this whole idea about ap
On 5 February 2014 13:14, Zane Bitter wrote:
> That's not a great example, because one DB server depends on the other,
> forcing them into updating serially anyway.
>
> I have to say that even in general, this whole idea about applying update
> policies to non-grouped resources doesn't make a wh
On 4 February 2014 08:51, Clint Byrum wrote:
> Excerpts from Robert Collins's message of 2014-02-03 10:47:06 -0800:
>> Quick thoughts:
>>
>> - I'd like to be able to express a minimum service percentage: e.g. I
>> know I need 80% of my capacity available at anyone time, so an
>> additional constr
On Tue, Feb 4, 2014 at 6:14 PM, Zane Bitter wrote:
> On 03/02/14 17:09, Clint Byrum wrote:
>
>> Excerpts from Thomas Herve's message of 2014-02-03 12:46:05 -0800:
>>
>>>
> update behavior. I want this resource to be able to control multiple
>> groups as if they are one in some cases (Such a
On 03/02/14 17:09, Clint Byrum wrote:
Excerpts from Thomas Herve's message of 2014-02-03 12:46:05 -0800:
So, I wrote the original rolling updates spec about a year ago, and the
time has come to get serious about implementation. I went through it and
basically rewrote the entire thing to reflect
> > I then feel that using (abusing?) depends_on for update pattern is a bit
> > weird. Maybe I'm influenced by the CFN design, but the separate
> > UpdatePolicy attribute feels better (although I would probably use a
> > property). I guess my main question is around the meaning of using the
> > u
Thomas Herve wrote on 03/02/2014 21:46:05:
> From: Thomas Herve
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 03/02/2014 21:52
> Subject: Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec
> re-written. RFC
>
> > So,
Excerpts from Thomas Herve's message of 2014-02-03 12:46:05 -0800:
> > So, I wrote the original rolling updates spec about a year ago, and the
> > time has come to get serious about implementation. I went through it and
> > basically rewrote the entire thing to reflect the knowledge I have
> > gain
Heya Clint, this BP looks really good - it should significantly simplify
the implementation of scaling if this becomes a core Heat feature. Comments
below.
On Mon, Feb 3, 2014 at 2:46 PM, Thomas Herve wrote:
> > So, I wrote the original rolling updates spec about a year ago, and the
> > time has
> So, I wrote the original rolling updates spec about a year ago, and the
> time has come to get serious about implementation. I went through it and
> basically rewrote the entire thing to reflect the knowledge I have
> gained from a year of working with Heat.
>
> Any and all comments are welcome.
Excerpts from Robert Collins's message of 2014-02-03 10:47:06 -0800:
> Quick thoughts:
>
> - I'd like to be able to express a minimum service percentage: e.g. I
> know I need 80% of my capacity available at anyone time, so an
> additional constraint to the unit counts, is to stay below 20% down a
Quick thoughts:
- I'd like to be able to express a minimum service percentage: e.g. I
know I need 80% of my capacity available at anyone time, so an
additional constraint to the unit counts, is to stay below 20% down at
a time (and this implies that if 20% have failed, either stop or spin
up more
So, I wrote the original rolling updates spec about a year ago, and the
time has come to get serious about implementation. I went through it and
basically rewrote the entire thing to reflect the knowledge I have
gained from a year of working with Heat.
Any and all comments are welcome. I intend to
19 matches
Mail list logo
