Open Stack

Hi Steve,

Great that you are looking at what is happening on other Openstack APIs with an eye toward consistency. We need more of this.

A few thoughts on tenant_id within  your APIs.


*        How are you proposing to allow cross tenant access? For example, the case where one tenant has an admin role to access another tenant's resources.  With existing OS APIs which organize resources by tenant, {tenantId}/resources/... , the admin's tenant & role are part of the Keystone headers so it is straightforward for the service to control this. Quantum 2.0 has proposed an query param '? tenant_id=X' to handle this.



*        Do you need to handle a use case where you would move stacks from one tenant to another? How would this be done with no tenant_id in the resource?

Thanks,
Peter.



From: Steve Baker [mailto:sbaker at redhat.com]
Sent: Sunday, November 11, 2012 12:42 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs

On 11/10/2012 03:09 PM, Dolph Mathews wrote:
I don't think anyone is suggesting to completely remove tenant ID's from URLs across OpenStack; I think Juergen Brendel summarized it really well: "From a purely RESTful standpoint, no tenant ID is needed as long as the URI remains unique to the resource."

We're still designing v1 of the Heat REST API so we have a chance of getting it right the first time. I'd like to use this thread to get some advice.

We've just switched our stack ID from an incrementing integer to a UUID. Each stack also has a user assigned name which is unique within the tenant.

Currently our list and show URLs are:
/{tenant_id}/stacks
/{tenant_id}/stacks/{name}/{id}

Now that we use UUIDs we can do the following for show:
/{tenant_id}/stacks/{uuid}

However this thread suggests we need just enough in the URI to make it uniquely map to content, which would make our list and show:
/{tenant_id}/stacks
/stacks/{uuid}

This would make the client more complex. Right now the endpoint from Keystone has the tenant ID, so all REST URLs just append to that. It seems more error-prone to leave it up to the client to know when to prepend the tenant ID.

As a nice to have feature, our CLI should also be able to do operations on a stack name as well as a uuid. Looking at quantum (whose REST API is completely absent from api.openstack.org btw ;) their client maps from name->uuid by:
- check to see if the identifier matches a uuid pattern, and if not
- uuid = GET /{tenant_id}/stacks?name={identifier}&fields=id
- /{tenant_id}/stacks/{uuid}...

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121111/aa8481d8/attachment.html>