<tt><font size=2>Steven Hardy <shardy@redhat.com> wrote on 07/02/2014
06:16:21 AM:<br>
<br>
> On Wed, Jul 02, 2014 at 02:41:19AM +0000, Adrian Otto wrote:<br>
> >    Zane,<br>
> >    If you happen to have a link to this blueprint,
could you replywith it? ...</font></tt>
<br><tt><font size=2>><br>
> I believe Zane was referring to:<br>
> <br>
> </font></tt><a href="https://blueprints.launchpad.net/heat/+spec/update-hooks"><tt><font size=2>https://blueprints.launchpad.net/heat/+spec/update-hooks</font></tt></a><tt><font size=2><br>
> <br>
> This is also related to the action aware software config spec:<br>
> <br>
> </font></tt><a href=https://review.openstack.org/#/c/98742/><tt><font size=2>https://review.openstack.org/#/c/98742/</font></tt></a><tt><font size=2><br>
> <br>
> So in future, you might autoscale nested stacks containing action-aware<br>
> software config resources, then you could define specific actions
which<br>
> happen e.g on scale-down (on action DELETE).<br>
</font></tt>
<br><tt><font size=2>Thanks, those are great pointers.  The second
pretty much covers the first, right?</font></tt>
<br>
<br><tt><font size=2>I do think the issue these address --- the need to
get application logic involved in, e.g., shutdown --- is most of what an
application needs; involvement in selection of which member(s) to delete
is much less important (provided that clean shutdown mechanism prevents
concurrent shutdowns).  So that provides a pretty good decoupling
between the application's concerns and a holistic scheduler's concerns.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>