Open Stack

On Thu, Nov 14, 2013 at 10:46 AM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

> Hi,
>
> 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
> https://blueprints.launchpad.net/heat/+spec/autoscaling-instancse-typization.
> 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.
>
>

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.



> Thanks
> Georgy
>
>
> On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter <zbitter at redhat.com> wrote:
>
>> On 14/11/13 17:19, Christopher Armstrong 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?
>>> - how webhooks are done (though this shouldn't affect the API too much;
>>> they're basically just opaque)
>>>
>>
>> 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:
>>  - names must be unique per-tenant
>>  - the tenant-id appears in the endpoint URL
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>>  Please read and comment :)
>>>
>>
>> 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.
>>
>> Successful creates should return 201 Created, not 200 OK.
>>
>> Responses from creates should include the UUID as well as the URI.
>> (Getting into minor details here.)
>>
>> Policies are scoped within groups, so do they need a unique id or would a
>> name do?
>>
>> 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?)
>>
>> 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'?
>>
>> 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).
>>
>> cheers,
>> Zane.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
IRC: radix
Christopher Armstrong
Rackspace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/5a126258/attachment.html>