Open Stack

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?

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.

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 ...?

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.

(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.)

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.

Heat will have a resource type, analogous to 
AWS::AutoScaling::AutoScalingGroup, through which the template author can 
request usage of the AS service.

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.

Have I got this right?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130919/c65a98e3/attachment.html>