Open Stack

On 14/11/13 19:53, Christopher Armstrong wrote:
> Thanks for the comments, Zane.
>
>
> On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> wrote:
>     A few comments...
>
>     #1 thing is that the launch configuration needs to be somehow
>     represented. In general we want the launch configuration to be a
>     provider template, but we'll want to create a shortcut for the
>     obvious case of just scaling servers. Maybe we pass a provider
>     template (or URL) as well as parameters, and the former is optional.
>
>
> I'm a little unclear as to what point you're making here. Right now, the
> "launch configuration" is specified in the scaling group by the
> "resources" property of the request json body. It's not a full template,
> but just a "snippet" of a set of resources you want scaled.

Right, and this has a couple of effects, particularly for Heat:
1) You can't share a single launch config between scaling groups - this 
hurts composability of templates.
2) The AWS::EC2::Launch config wouldn't correspond to a real API, so we 
would have to continue to implement it using the current hack.

Fixing (2) is one of my top two reasons for even having an autoscaling API.

> As an aside, maybe we should replace this with a singlular "resource"
> and allow people to use a Stack resource if they want to represent
> multiple resources.
>
> I guess we can have a simpler API for using an old-style,
> server-specific "launch configuration", but I am skeptical of the
> benefit, since specifying a single Instance resource is pretty simple.

See my other message for implementation suggestion.

>     I'm not sure I understand the webhooks part... webhook-exec is the
>     thing that e.g. Ceilometer will use to signal an alarm, right? Why
>     is it not called something like
>     /groups/{group_id}/policies/{__policy_id}/alarm ? (Maybe because it
>     requires different auth middleware? Or does it?)
>
>
> Mostly because it's unnecessary. The idea was to generate a secret,
> opaque, revokable ID that maps to the specific policy.
> Â

Seems like it would be nice to look at the webhook URL and be able to 
figure out what it's for. I disagree that a secret URL is sufficient 
here, but even if it were it could be something like:

/groups/{group_id}/policies/{policy_name}/alarm/{secret_code}

>
>     And the other ones are setting up the notification actions? Can we
>     call them notifications instead of webhooks? (After all, in the
>     future we will probably want to add Marconi support, and maybe even
>     Mistral support.) And why are these attached to the policy? Isn't
>     the notification connected to changes in the group, rather than
>     anything specific to the policy? Am I misunderstanding how this
>     works? What is the difference between 'uri' and 'capability_uri'?
>
>
>
> Policies represent ways to change a group ("add +5% to this group").
> Webhooks execute policies.
>
> A "capability URI" is a URI which represents a capability to do
> something all by itself. capability_uri would be the webhook-exec thing.
> The regular URI would be the thing under
> /groups/{group_id}/policies/{policy_id}/webhooks. That URI needs to
> exist so you can perform the DELETE operation on it. (but you can't
> DELETE the capability_uri, only POST to it to execute the policy).
> Â

Oh, I was misunderstanding... this doesn't set up the notifications, it 
allows you to create and revoke multiple webhook URLs for the alarms.

I have reservations about this whole area.

> I'll think more about webhooks vs notifications.

Seems like a way to configure the notifications is missing altogether.

cheers,
Zane.