Open Stack

I agree with Eugene that the tenant_id is not necessary in the URI.
Euguene also has a good point on shared resources - and on this note I
would like to remark that at the moment we have a very simple sharing model
in Quantum. The model is that a network can either be shared with everybody
or stay private. We are aware that this is fairly trivial, but suited
Quantum needs for the Folsom release. If we find out we need to improve
this mechanism, we'll do it - as long as keep the API backward compatible!

I believe that Peter's initial note was about consistency across all
openstack projects. Dan provided probably the most reasonable explanation
for this - I tried to provide similar reasons in another thread but that
was more of a guess as I wasn't very active on the project at the time
(yeah, that a lame excuse... I know).

>From a user perspective we understand that consistency across APIs for
different projects is very important. As user I would be at least perplexed
by this difference.
On the other hand, reintroducing the tenant_id in the URI structure and
thus 'uniforming' to other Openstack projects, would likely represent a
backward incompatible change for our API, and then is a very delicate
decision to take.

Salvatore

On 2 November 2012 06:04, Eugene Nikanorov <enikanorov at mirantis.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/0c0f5bdf/attachment-0001.html>