<div dir="ltr">On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt <span dir="ltr"><<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
Good stuff! Some questions/comments:
<div><br>
</div>
<div>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?</div>

<div><br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
</div>
<div>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.</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br>
<div>
<div>On Nov 14, 2013, at 10:57 AM, Randall Burt <<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>></div>
<div> wrote:</div><div><div class="h5">
<br>
<blockquote type="cite">
<div style="word-wrap:break-word">
<br>
<div>
<div>On Nov 14, 2013, at 10:19 AM, Christopher Armstrong <<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a>></div>
<div> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr"><a href="http://docs.heatautoscale.apiary.io/" target="_blank">http://docs.heatautoscale.apiary.io/</a>
<div><br>
</div>
<div>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 <a href="https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp" target="_blank">https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp</a></div>

<div><br>
</div>
<div><br>
</div>
<div>Things we still need to figure out:</div>
<div><br>
</div>
<div>- how to scope projects/domains. put them in the URL? get them from the token?</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>- how webhooks are done (though this shouldn't affect the API too much; they're basically just opaque)</div>
<div><br>
</div>
<div>Please read and comment :)</div>
<div><br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div>IRC: radix</div>
Christopher Armstrong
<div>Rackspace</div>
</div>
</div>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div></div></div>
<br>
</div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>IRC: radix</div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>