Open Stack

+1  I think URLs w/o tenant IDs are a cleaner design.

thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug at us.ibm.com
The more I'm around some people, the more I like my dog.



From:	Eugene Nikanorov <enikanorov at mirantis.com>
To:	OpenStack Development Mailing List
            <openstack-dev at lists.openstack.org>,
Date:	11/02/2012 02:13 AM
Subject:	Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API
            URLs and Quatum 2.0 APIs



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/60c99da8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121102/60c99da8/attachment.gif>