> 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 

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?

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.



OpenStack-dev mailing list

Reply via email to