Hi Michael! Thanks for this summary. There were some minor inaccuracies, but I appreciate you at least trying when I should have summarized it earlier. I'll give some feedback inline.
First, though, I have recently worked a lot on the wiki page for the blueprint. It's available here: https://wiki.openstack.org/wiki/Heat/AutoScaling It still might need a little bit more cleaning up and probably a more holistic example, but it should be pretty close now. I will say that I changed it to specify the Heat resources for using autoscale instead of the APIs of the AS API mostly for convenience because they're easily specifiable. The AS API should be derived pretty obviously from the resources. On Thu, Sep 19, 2013 at 6:35 AM, Mike Spreitzer <[email protected]> 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? Yeah. Sorry I didn't link that wiki page earlier; it was in a pretty raw and chaotic form. > 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?). Yes. See the wiki page above; it's basically just a mapping exactly like the "Resources" section in a typical Heat template. e.g. {..., "Resources": {"mywebserver": {"Type": "OS::Nova::Server"}, ...}} > 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. This is accurate. > 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 ...? The webhook provides no parameters. The amount of change is encoded into the policy that the webhook is associated with. Policies can change it the same way they can in current AWS-based autoscaling: +/- fixed number, or +/- percent, or setting it to a specific number directly. > 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. I don't think the webhook is the right place to do that. That should probably be a specific thing in the AS API. > (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.) I think the policies are what qualify it for the "auto" term. You can have webhook policies or schedule-based policies (and maybe more policies in the future). The policies determine how to change the group. > 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. Agreed. > Heat will have a resource type, analogous to > AWS::AutoScaling::AutoScalingGroup, through which the template author can > request usage of the AS service. Yes. > 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. Agreed. > Have I got this right? Pretty much! Thanks for the summary :-) -- IRC: radix Christopher Armstrong Rackspace _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
