On 09/19/2013 04:35 AM, Mike Spreitzer wrote:
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?
Mike,
The key contention to a separate API is that Heat already provides all
of this today. It is unclear to me how separating a specially designed
autoscaling service from Heat would be of big benefit because we still
need the launch configuration and properties of the autoscaling group to
be specified. A separate service may specify this in REST API calls,
whereas heat specifies it in a template, but really, this isn't much of
a difference from a user's view. The user still has to pass all of the
same data set in some way. Then there is the issue of duplicated code
for at-least handling the creation and removal of the server instances
themselves, and the bootstrapping that occurs in the process.
Your thread suggests we remove the "auto" from the "scaling" - these two
concepts seem tightly integrated to me, and my personal opinion is doing
so is just a way to work around the need to pass all of the necessary
autoscaling parameters in API calls. IMO there is no real benefit in a
simple scaling service that is directed by a third party software
component (in the proposed case Heat, activated on Ceilometer Alarms).
It just feels like it doesn't "do enough" to warrant an entire OpenStack
program. There is significant overhead in each OS program added and I
don't see the gain for the pain.
I think these are the main points of contention at this point, with no
clear consensus.
An alternate point in favor of a separate autoscaling component not
mentioned in your post is that an API produces a more composable[1]
system which brings many advantages.
Regards
-steve
[1] http://en.wikipedia.org/wiki/Composability
Thanks,
Mike
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
