<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 14, 2013 at 10:46 AM, Georgy Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>It would be great if API specs contain a list of attributes\parameters one can pass during group creation. I believe Zane already asked about LaunchConfig, but I think new autoscaling API creation was specifically designed to move from limited AWS ElasticLB to something with more broad features. There is a BP I submitted while ago <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-instancse-typization" target="_blank">https://blueprints.launchpad.net/heat/+spec/autoscaling-instancse-typization</a>. We discussed it in IRC chat with heat team and we got to the conclusion that this will be supported in new autoscaling API. Probably it is already supported, but it is quite hard to figure this out from the existing API specs without examples.</div>
<div><br></div></div></blockquote><div><br></div><div><br></div><div>The API spec does contain a list of attributes/parameters that you can pass during group creation (and all the other operations) -- see the Schema sections under each. In case you didn't notice, you can click on each action to expand details under it.</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 dir="ltr"><div></div><div>Thanks</div><div>Georgy </div></div><div class="gmail_extra">
<div><div class="h5"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 14/11/13 17:19, Christopher Armstrong wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<a href="http://docs.heatautoscale.apiary.io/" target="_blank">http://docs.heatautoscale.<u></u>apiary.io/</a><br>
<br>
I've thrown together a rough sketch of the proposed API for autoscaling.<br>
It's written in API-Blueprint format (which is a simple subset of<br>
Markdown) and provides schemas for inputs and outputs using JSON-Schema.<br></div>
The source document is currently atÂ<div><br>
<a href="https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp" target="_blank">https://github.com/radix/heat/<u></u>raw/as-api-spike/autoscaling.<u></u>apibp</a><br>
<br>
<br>
Things we still need to figure out:<br>
<br>
- how to scope projects/domains. put them in the URL? get them from the<br>
token?<br>
- how webhooks are done (though this shouldn't affect the API too much;<br>
they're basically just opaque)<br>
</div></blockquote>
<br>
My 2c: the way I designed the Heat API was such that extant stacks can be addressed uniquely by name. Humans are pretty good with names, not so much with 128 bit numbers. The consequences of this for the design were:<br>
- names must be unique per-tenant<br>
- the tenant-id appears in the endpoint URL<br>
<br>
However, the rest of OpenStack seems to have gone in a direction where the "name" is really just a comment field, everything is addressed only by UUID. A consequence of this is that it renders the tenant-id in the URL pointless, so many projects are removing it.<br>
<br>
Unfortunately, one result is that if you create a resource and e.g. miss the Created response for any reason and thus do not have the UUID, there is now no safe, general automated way to delete it again. (There are obviously heuristics you could try.) To solve this problem, there is a proposal floating about for clients to provide another unique ID when making the request, which would render a retry of the request idempotent. That's insufficient, though, because if you decide to roll back instead of retry you still need a way to delete using only this ID.<br>
<br>
So basically, that design sucks for both humans (who have to remember UUIDs instead of names) and machines (Heat). However, it appears that I am in a minority of one on this point, so take it with a grain of salt.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please read and comment :)<br>
</blockquote>
<br></div>
A few comments...<br>
<br>
#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.<br>
<br>
Successful creates should return 201 Created, not 200 OK.<br>
<br>
Responses from creates should include the UUID as well as the URI. (Getting into minor details here.)<br>
<br>
Policies are scoped within groups, so do they need a unique id or would a name do?<br>
<br>
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/{<u></u>policy_id}/alarm ? (Maybe because it requires different auth middleware? Or does it?)<br>
<br>
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'?<br>
<br>
You need to define PUT/PATCH methods for most of these also, obviously (I assume you just want to get this part nailed down first).<br>
<br>
cheers,<br>
Zane.<div><div><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996 3284</a><br>
</font></span></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>