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 <[email protected]>wrote: > > 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?). > > Agreed. > 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 agree that depends_on is weird and I think it should be avoided. I'm not sure a property is the right decision, though, assuming that it's the heat engine that's dealing with the rolling updates -- I think having the engine reach into a resource's properties would set a strange precedent. The CFN design does seem pretty reasonable to me, assuming an "update_policy" field in a HOT resource, referring to the policy that the resource should use. 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. > > Yeah, this would be really helpful for stuff like load balancer notifications (and any of a number of different resource relationships). -- IRC: radix http://twitter.com/radix Christopher Armstrong Rackspace
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
