Open Stack

Folks,

Let me add my 2c to this discussion.

Objects in Quantum could be identified by their Id, so why specify
tenant_id+object_id in URL when object_id is sufficient?
If we're talking about authorization then keystone middleware adds header
with tenant_id allowing to make authorization decision.
If we're talking about cross tenant access, e.g. when one tenant accesses
resource created by another, that implies that there is:
- API for creating/listing such shared resources
- each resource could still be accessed by ID
- resource is marked as shared so Quantum will authorize any tenant to
access it

So actually there is no direct need in tenant_id in URL.

Thanks,
Eugene.

On Fri, Nov 2, 2012 at 2:30 AM, Dan Wendlandt <dan at nicira.com> wrote:

> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20121102/510a9c5d/attachment.html>