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? _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
