<tt><font size=2>Daniel Comnea <comnea.dani@gmail.com> wrote on
10/27/2014 07:16:32 AM:<br>
<br>
> Yes i did but if you look at this example<br>
> <br>
> </font></tt><a href="https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml"><tt><font size=2>https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>
<br><tt><font size=2>> the flow is simple:<br>
</font></tt>
<br><tt><font size=2>> CPU alarm in Ceilometer triggers the "type:
OS::Heat::ScalingPolicy"<br>
> which then triggers the "type: OS::Heat::AutoScalingGroup"<br>
</font></tt>
<br><tt><font size=2>Actually the ScalingPolicy does not "trigger"
the ASG.  BTW, "ScalingPolicy" is mis-named; it is not a
full policy, it is only an action (the condition part is missing --- as
you noted, that is in the Ceilometer alarm).  The so-called ScalingPolicy
does the action itself when triggered.  But it respects your configured
min and max size.</font></tt>
<br>
<br><tt><font size=2>What are you concerned about making your scaling group
smaller than your configured minimum?  Just checking here that there
is not a misunderstanding.</font></tt>
<br>
<br><tt><font size=2>As Clint noted, there is a large-scale effort underway
to make Heat maintain what it creates despite deletion of the underlying
resources.</font></tt>
<br>
<br><tt><font size=2>There is also a small-scale effort underway to make
ASGs recover from members stopping proper functioning for whatever reason.
 See </font></tt><a href=https://review.openstack.org/#/c/127884/><tt><font size=2 color=blue>https://review.openstack.org/#/c/127884/</font></tt></a><tt><font size=2>
for a proposed interface and initial implementation.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>