Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/93b0d78d/attachment.html>