[openstack-dev] [Heat] rough draft of Heat autoscaling API

Randall Burt randall.burt at RACKSPACE.COM
Thu Nov 14 17:51:59 UTC 2013


On Nov 14, 2013, at 11:30 AM, Christopher Armstrong <chris.armstrong at rackspace.com<mailto:chris.armstrong at rackspace.com>>
 wrote:

On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt <randall.burt at rackspace.com<mailto:randall.burt at rackspace.com>> wrote:
Good stuff! Some questions/comments:

If web hooks are associated with policies and policies are independent entities, how does a web hook specify the scaling group to act on? Does calling the web hook activate the policy on every associated scaling group?


Not sure what you mean by "policies are independent entities". You may have missed that the policy resource lives hierarchically under the group resource. Policies are strictly associated with one scaling group, so when a policy is executed (via a webhook), it's acting on the scaling group that the policy is associated with.

Whoops. Yeah, I missed that.



Regarding web hook execution and cool down, I think the response should be something like 307 if the hook is on cool down with an appropriate retry-after header.

Indicating whether a webhook was found or whether it actually executed anything may be an information leak, since webhook URLs require no additional authentication other than knowledge of the URL itself. Responding with only 202 means that people won't be able to guess at random URLs and know when they've found one.

Perhaps, but I also miss important information as a legitimate caller as to whether or not my scaling action actually happened or I've been a little too aggressive with my curl commands. The fact that I get anything other than 404 (which the spec returns if its not a legit hook) means I've found *something* and can simply call it endlessly in a loop causing havoc. Perhaps the web hooks *should* be authenticated? This seems like a pretty large hole to me, especially if I can max someone's resources by guessing the right url.


On Nov 14, 2013, at 10:57 AM, Randall Burt <randall.burt at rackspace.com<mailto:randall.burt at rackspace.com>>
 wrote:


On Nov 14, 2013, at 10:19 AM, Christopher Armstrong <chris.armstrong at rackspace.com<mailto:chris.armstrong at rackspace.com>>
 wrote:

http://docs.heatautoscale.apiary.io/

I've thrown together a rough sketch of the proposed API for autoscaling. It's written in API-Blueprint format (which is a simple subset of Markdown) and provides schemas for inputs and outputs using JSON-Schema. The source document is currently at https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp


Things we still need to figure out:

- how to scope projects/domains. put them in the URL? get them from the token?

This may be moot considering the latest from the keystone devs regarding token scoping to domains/projects. Basically, a token is scoped to a single domain/project from what I understood, so domain/project is implicit. I'm still of the mind that the tenant doesn't belong so early in the URI, since we can already surmise the actual tenant from the authentication context, but that's something for Openstack at large to agree on.

- how webhooks are done (though this shouldn't affect the API too much; they're basically just opaque)

Please read and comment :)


--
IRC: radix
Christopher Armstrong
Rackspace
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
IRC: radix
Christopher Armstrong
Rackspace
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/29ae2592/attachment.html>


More information about the OpenStack-dev mailing list