Open Stack

On 27/11/13 18:16, Jay Pipes wrote:
> On 11/27/2013 12:02 PM, Zane Bitter wrote:
>> Your proposal on the wiki page retains this URL but removes the tenant
>> ID:
>>
>>     GET /v2/stacks/{stack_name}
>>
>> This now no longer uniquely identifies a stack, and is therefore not
>> ReST.
>
> It would be along with a Vary: X-Project-Id header, no?

Sure, but the point of HTTP is that a URI addresses exactly one 
resource. A resource may have multiple representations and the one 
returned can depend on the headers, but a URI should never address more 
than one resource.

For example, you could easily imagine a situation where you end up 
getting served data for another tenant from a cache somewhere, which 
would be Very Bad.

>> So if we drop the tenant_id then we should also start addressing stacks
>> only by UUID:
>>
>>      GET v2/stacks/{stack_id}
>>
>> and do lookups by name using stack list or something. However other
>> projects do it.
>
> ++ for this anyway :)
>
>> This seems clearly worse than the API we have, but it would at least be
>> consistent with other OpenStack projects. For them this API makes more
>> sense, because they don't enforce unique names for things in a tenant
>> and probably couldn't start if they wanted to. This was IMHO a mistake,
>> and one that Heat avoided, but I accept that it's hard to escape gravity
>> on this. I, for one, welcome our new UUID overlords.
>
> LOL. Actually, in Nova and other places it's now moving to UNIQUE
> CONSTRAINT (name, project, deleted) ;)

Oh, perfect :) Then we should just keep the tenant_id and wait for 
everyone else to circle back around :D

Even better would be if we had the keystone domain (instead of the 
tenant id) incorporated into the endpoint in the keystone catalog and 
then we could use the tenant^W project *name* in the URL and users would 
never have to deal with UUIDs and invisible headers again - your server 
is always at /my-project-name/servers/my-server-name. Where you might 
expect it to be.

cheers,
Zane.