<font size=2 face="sans-serif">I'd like to try to summarize this discussion,
if nothing else than to see whether I have correctly understood it.  There
is a lot of consensus, but I haven't heard from Adrian Otto since he wrote
some objections.  I'll focus on trying to describe the consensus;
Adrian's concerns are already collected in a single message.  Or maybe
this is already written in some one place?</font>
<br>
<br><font size=2 face="sans-serif">The consensus is that there should be
an autoscaling (AS) service that is accessible via its own API.  This
autoscaling service can scale anything describable by a snippet of Heat
template (it's not clear to me exactly what sort of syntax this is; is
it written up anywhere?).  The autoscaling service is stimulated into
action by a webhook call.  The user has the freedom to arrange calls
on that webhook in any way she wants.  It is anticipated that a common
case will be alarms raised by Ceilometer.  For more specialized or
complicated logic, the user is free to wire up anything she wants to call
the webhook.</font>
<br>
<br><font size=2 face="sans-serif">An instance of the autoscaling service
maintains an integer variable, which is the current number of copies of
the thing being autoscaled.  Does the webhook call provide a new number,
or +1/-1 signal, or ...?</font>
<br>
<br><font size=2 face="sans-serif">There was some discussion of a way to
indicate which individuals to remove, in the case of decreasing the multiplier.
 I suppose that would be an option in the webhook, and one that will
not be exercised by Ceilometer alarms.</font>
<br>
<br><font size=2 face="sans-serif">(It seems to me that there is not much
"auto" in this autoscaling service --- it is really a scaling
service driven by an external controller.  This is not a criticism,
I think this is a good factoring --- but maybe not the best naming.)</font>
<br>
<br><font size=2 face="sans-serif">The autoscaling service does its job
by multiplying the heat template snippet (the thing to be autoscaled) by
the current number of copies and passing this derived template to Heat
to "make it so".  As the desired number of copies changes,
the AS service changes the derived template that it hands to Heat.  Most
commentators argue that the consistency and non-redundancy of making the
AS service use Heat outweigh the extra path-length compared to a more direct
solution.</font>
<br>
<br><font size=2 face="sans-serif">Heat will have a resource type, analogous
to AWS::AutoScaling::AutoScalingGroup, through which the template author
can request usage of the AS service.</font>
<br>
<br><font size=2 face="sans-serif">OpenStack in general, and Heat in particular,
need to be much better at traceability and debuggability; the AS service
should be good at these too.</font>
<br>
<br><font size=2 face="sans-serif">Have I got this right?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Mike</font>