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