> > 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.
OK. Part of my confusion is that I didn't really understand the relationship you're trying to build. > 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). We don't need to have the same restriction as CFN. > 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. I think I start to understand. The depends_on implicitly creates a group of children with the parent being your rolling update resource. > > 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? Sure, I don't want to block you. I think I'd rather have another name than depends_on, to make it more clear what it means, even if at the implementation detail they are roughly the same. Or maybe we shouldn't use depends_on in HOT. Something like "parent_resources" would seem closer to what we want. -- Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
