Open Stack

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 <mspreitz at us.ibm.com> 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