Open Stack

This is now ancient (in openstack time) history, but Quantum removed the
tenant-id from the URL when moving from v1 to v2 of the API because someone
(I forget who) had said that other OpenStack services already where (and/or
were planning) doing the same.  Unfortunately, as is somewhat often the
case, it seems like that sentiment may not have been quite as universal as
I was led to believe :)

Dan



On Thu, Nov 1, 2012 at 12:53 PM, Mellquist, Peter <peter.mellquist at hp.com>wrote:

>  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>
> 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****
>
>  ****
>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
>  ** **
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121101/39cb3746/attachment-0001.html>