Open Stack

On 15/11/13 16:32 +0100, Zane Bitter wrote:
>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.

IMHO we should not let the design be altered by aws resources.
- let lauchconfing be ugly.
- make the primary interface of a scaling unit be a nested stack (with
   our new config resources etc..)

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