Open Stack

Thanks Joe.

I was not involved in the creation of the Quantum 2.0 APIs so I cannot say for sure why the difference in tenant-id handling was made.  As part of a new Quantum sub-project LBaaS, we came across this difference and my reason for the posting was to gauge how everyone feels about this difference from a consistency perspective across all OS APIs.  Ideally I would like to see a common API pattern for handling this, if that makes sense. Keystone integration is a big part of how tenants are specified including the ability for cross tenant access so your input is very valuable here.

Peter.

From: heckj [mailto:heckj at mac.com]
Sent: Thursday, November 01, 2012 12:29 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs

Hey Peter,

I'm not sure that's an entirely safe assumption. Although that's totally what we're doing today, and in most implementations the authorization is scoped to a single tenant, there's a request outstanding to allow a token to be applicable to more than one tenant, which would leave this kind of request in a very indeterminate status if you're relying on Keystone.

I'm not terribly in favor of having a token scoped so widely - but it's technically possible to have a token that's scoped more broadly with the V2 API. V3 was attempting to lock that down to mandate a bit of interoperability, but so far there's a far bit of push back on wanting that open.

Needless to say, your feedback on that topic would be nice as it related to the Quantum 2.0 API.

For this specific purpose, I would encourage the API to require a specific tenant_id - either in the URL, or as part of the posted query parameter elements if it's tied to the resource in question (i.e CRUD operations that are specific to a tenant)


-joe

On Nov 1, 2012, at 12:15 PM, "Mellquist, Peter" <peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>> wrote:
The majority of the existing Openstack APIs allow specifying the tenant_id as part of the REST resource URL where resources are structured around tenants.  For example within nova APIs, these API calls are prefixed with /v2/{tenant_id} / ...  www.api.openstack.org<http://www.api.openstack.org/>

Quantum API 2.0 specifies a new way for APIs to reference tenant based resources. As part of the transition from the Quantum API 1.0 to 2.0 , the tenant_id as part of the resource URL has been dropped and instead the requested resource is assumed to be the Keystone derived tenant_id.  This shortens the Quantum API 2.0 calls to exclude {tenant_id} as part of the URL. For example, for LBaaS with Quantum 2.0 we would just have
/v1.0/...
For cross tenant access, when roles allow so, Quantum 2.0 allows specifying tenant_id as a query parameter, '? tenant_id=XXX.'

Does the Quantum 2.0 API work in terms of handling multi-tenant resource access? YES
Is the Quantum 2.0 API consistent with existing Openstack APIs in regard to tenant resource access? NO

Openstack API Community Questions:
Does consistency across Openstack APIs in regard to tenant based resource access matter?
Does this impact developers, direct REST usage or those using language bindings / libraries?

Thank You,
Peter Mellquist
Hewlett Packard Company

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121101/100b4f9f/attachment.html>