Thomas Herve <thomas.he...@enovance.com> wrote on 03/02/2014 21:46:05: > From: Thomas Herve <thomas.he...@enovance.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 03/02/2014 21:52 > Subject: Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec > re-written. RFC > > > 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?). > > 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 also think that the depends_on feels a bit weird. In most use cases depends_on is more about waiting for some other resource to be ready, but for rolling updates the resource if more a data container (a policy) only that is just there - that's at least how I understand it from a user's perspective. So refering to that resource via a special property would look more intuitive to me. That would also be in line with other cases already implemented: an InstanceGroup that points to its LaunchConfiguration; a SoftwareDeployment that points to a SoftwareConfiguration. > > 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. > > Thanks, > > -- > Thomas > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
