Open Stack

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 a year of working with Heat.
> > 
> > Any and all comments are welcome. I intend to start implementation very
> > soon, as this is an important component of the HA story for TripleO:
> > 
> > https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates
> 
> Hi Clint, thanks for pushing this.
> 
> 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 UpdatePattern.

> 
> 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 pattern on a server instance. I think I see what you want to do for the group, where child_updating would return a number, but I have no idea what it means for a single resource. Could you detail the operation a bit more in the document?
> 

I would be o-k with adding another keyword. The idea in abusing depends_on
is that it changes the core language less. Properties is definitely out
for the reasons Christopher brought up, properties is really meant to
be for the resource's end target only.

UpdatePolicy in cfn is a single string, and causes very generic rolling
update behavior. I want this resource to be able to control multiple
groups as if they are one in some cases (Such as a case where a user
has migrated part of an app to a new type of server, but not all.. so
they will want to treat the entire aggregate as one rolling update).

I'm o-k with overloading it to allow resource references, but I'd like
to hear more people take issue with depends_on before I select that
course.

To answer your question, using it with a server instance allows
rolling updates across non-grouped resources. In the example the
rolling_update_dbs does this.

> It also seems that the interface you're creating (child_creating/child_updating) is fairly specific to your use case. For autoscaling we have a need for more generic notification system, it would be nice to find common grounds. Maybe we can invert the relationship? Add a "notified_resources" attribute, which would call hooks on the "parent" when actions are happening.
> 

I'm open to a different interface design. I don't really have a firm
grasp of the generic behavior you'd like to model though. This is quite
concrete and would be entirely hidden from template authors, though not
from resource plugin authors. Attributes sound like something where you
want the template authors to get involved in specifying, but maybe that
was just an overloaded term.

So perhaps we can replace this interface with the generic one when your
use case is more clear?