<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Heya Clint, this BP looks really good - it should significantly simplify the implementation of scaling if this becomes a core Heat feature. Comments below.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Feb 3, 2014 at 2:46 PM, Thomas Herve <span dir="ltr"><<a href="mailto:thomas.herve@enovance.com" target="_blank">thomas.herve@enovance.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> So, I wrote the original rolling updates spec about a year ago, and the<br>
> time has come to get serious about implementation. I went through it and<br>
> basically rewrote the entire thing to reflect the knowledge I have<br>
> gained from a year of working with Heat.<br>
><br>
> Any and all comments are welcome. I intend to start implementation very<br>
> soon, as this is an important component of the HA story for TripleO:<br>
><br>
> <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates" target="_blank">https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates</a><br>
<br>
</div>Hi Clint, thanks for pushing this.<br>
<br>
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?).<br>
<br></blockquote><div><br></div><div>Agreed.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>

<br></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

<br></blockquote><div><br></div><div><br></div><div>Yeah, this would be really helpful for stuff like load balancer notifications (and any of a number of different resource relationships).<br clear="all"><div><br></div>-- <br>
<div dir="ltr"><div>IRC: radix</div><div><a href="http://twitter.com/radix">http://twitter.com/radix</a></div>Christopher Armstrong<div>Rackspace</div></div>
<br><br></div></div>
</div></div>