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
On 02/04/2014 06:34 PM, Robert Collins wrote:
On 5 February 2014 13:14, Zane Bitter zbit...@redhat.com 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
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
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 zbit...@redhat.com wrote:
That's not a great example, because one DB server depends on the other,
forcing them into updating serially
On 04/02/14 20:34, Robert Collins wrote:
On 5 February 2014 13:14, Zane Bitter zbit...@redhat.com 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
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?
Thomas Herve thomas.he...@enovance.com wrote on 03/02/2014 21:46:05:
From: Thomas Herve thomas.he...@enovance.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 03/02/2014 21:52
Subject: Re: [openstack-dev] [Heat] [TripleO] Rolling
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
update
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
On Tue, Feb 4, 2014 at 6:14 PM, Zane Bitter zbit...@redhat.com 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
On 4 February 2014 08:51, Clint Byrum cl...@fewbar.com 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
On 5 February 2014 13:14, Zane Bitter zbit...@redhat.com 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
On Tue, Feb 4, 2014 at 7:34 PM, Robert Collins robe...@robertcollins.netwrote:
On 5 February 2014 13:14, Zane Bitter zbit...@redhat.com 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
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
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
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 at
a
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
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 thomas.he...@enovance.comwrote:
So, I wrote the original rolling updates spec about a year
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
gained from
19 matches
Mail list logo
