Open Stack

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 <thomas.herve at enovance.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140203/2918e641/attachment.html>