<html><body>
<p><font size="2" face="sans-serif">+1 I think URLs w/o tenant IDs are a cleaner design.<br>
<br>
thanks<br>
-Doug<br>
________________________________________________________<br>
STSM | Standards Architect | IBM Software Group<br>
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com<br>
The more I'm around some people, the more I like my dog.</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF039DFD4AD2A8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Eugene Nikanorov ---11/02/2012 02:13:17 AM---Folks, Let me add my 2c to this discussion."><font size="2" color="#424282" face="sans-serif">Eugene Nikanorov ---11/02/2012 02:13:17 AM---Folks, Let me add my 2c to this discussion.</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Eugene Nikanorov <enikanorov@mirantis.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">11/02/2012 02:13 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="3" face="serif">Folks, </font><br>
<br>
<font size="3" face="serif">Let me add my 2c to this discussion.</font><br>
<br>
<font size="3" face="serif">Objects in Quantum could be identified by their Id, so why specify tenant_id+object_id in URL when object_id is sufficient?</font><br>
<font size="3" face="serif">If we're talking about authorization then keystone middleware adds header with tenant_id allowing to make authorization decision.</font><br>
<font size="3" face="serif">If we're talking about cross tenant access, e.g. when one tenant accesses resource created by another, that implies that there is: </font><br>
<font size="3" face="serif">- API for creating/listing such shared resources</font><br>
<font size="3" face="serif">- each resource could still be accessed by ID</font><br>
<font size="3" face="serif">- resource is marked as shared so Quantum will authorize any tenant to access it<br>
<br>
So actually there is no direct need in tenant_id in URL.<br>
<br>
Thanks,</font><br>
<font size="3" face="serif">Eugene.<br>
</font><br>
<font size="3" face="serif">On Fri, Nov 2, 2012 at 2:30 AM, Dan Wendlandt <</font><a href="mailto:dan@nicira.com" target="_blank"><font size="3" color="#0000FF" face="serif"><u>dan@nicira.com</u></font></a><font size="3" face="serif">> wrote:</font>
<ul style="padding-left: 9pt"><font size="3" face="serif">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 :) </font><br>
<br>
<font size="3" face="serif">Dan</font><br>
<br>
<font size="3" face="serif"><br>
</font><br>
<font size="3" face="serif">On Thu, Nov 1, 2012 at 12:53 PM, Mellquist, Peter <</font><a href="mailto:peter.mellquist@hp.com" target="_blank"><font size="3" color="#0000FF" face="serif"><u>peter.mellquist@hp.com</u></font></a><font size="3" face="serif">> wrote:</font>
<ul style="padding-left: 9pt"><font size="2" color="#1F497D" face="Calibri">Thanks Joe.</font>
<p><font size="2" color="#1F497D" face="Calibri"> </font>
<p><font size="2" color="#1F497D" face="Calibri">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.</font>
<p><font size="2" color="#1F497D" face="Calibri"> </font>
<p><font size="2" color="#1F497D" face="Calibri">Peter.</font>
<p><font size="2" color="#1F497D" face="Calibri"> </font>
<p><font size="2" face="Tahoma"><b>From:</b></font><font size="2" face="Tahoma"> heckj [mailto:</font><a href="mailto:heckj@mac.com" target="_blank"><font size="2" color="#0000FF" face="Tahoma"><u>heckj@mac.com</u></font></a><font size="2" face="Tahoma">] </font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> Thursday, November 01, 2012 12:29 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">Hey Peter,</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">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.</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">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.</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">Needless to say, your feedback on that topic would be nice as it related to the Quantum 2.0 API.</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">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)</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">-joe</font>
<p><font size="3" face="serif"> </font>
<p><font size="3" face="serif">On Nov 1, 2012, at 12:15 PM, "Mellquist, Peter" <</font><a href="mailto:peter.mellquist@hp.com" target="_blank"><font size="3" color="#0000FF" face="serif"><u>peter.mellquist@hp.com</u></font></a><font size="3" face="serif">> wrote:</font>
<ul style="padding-left: 36pt"><font size="2" face="Calibri">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} / ... </font><a href="http://www.api.openstack.org/" target="_blank"><font size="2" color="#800080" face="Calibri"><u>www.api.openstack.org</u></font></a>
<p><font size="2" face="Calibri"> </font>
<p><font size="2" face="Calibri">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</font>
<p><font size="2" face="Calibri">/v1.0/…</font>
<p><font size="2" face="Calibri">For cross tenant access, when roles allow so, Quantum 2.0 allows specifying tenant_id as a query parameter, ‘? tenant_id=XXX.’</font>
<p><font size="2" face="Calibri"> </font>
<p><font size="2" face="Calibri">Does the Quantum 2.0 API work in terms of handling multi-tenant resource access? YES</font>
<p><font size="2" face="Calibri">Is the Quantum 2.0 API consistent with existing Openstack APIs in regard to tenant resource access? NO</font>
<p><font size="2" face="Calibri"> </font>
<p><font size="2" face="Calibri">Openstack API Community Questions:</font>
<p><font size="2" face="Calibri">Does consistency across Openstack APIs in regard to tenant based resource access matter?</font>
<p><font size="2" face="Calibri">Does this impact developers, direct REST usage or those using language bindings / libraries?</font>
<p><font size="2" face="Calibri"> </font>
<p><font size="2" face="Calibri">Thank You,</font>
<p><font size="2" face="Calibri">Peter Mellquist</font>
<p><font size="2" face="Calibri">Hewlett Packard Company</font>
<p><font size="2" face="Calibri"> </font>
<p><font size="4" face="Arial">_______________________________________________<br>
OpenStack-dev mailing list</font><font size="4" color="#0000FF" face="Arial"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank"><font size="4" color="#800080" face="Arial"><u>OpenStack-dev@lists.openstack.org</u></font></a><font size="4" color="#0000FF" face="Arial"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="4" color="#800080" face="Arial"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a></ul>
<br>
<font size="3" face="serif"> </font><br>
<font size="3" face="serif"><br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank"><font size="3" color="#0000FF" face="serif"><u>OpenStack-dev@lists.openstack.org</u></font></a><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="#0000FF" face="serif"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="serif"><br>
</font></ul>
<font size="3" face="serif"><br>
</font><br>
<br>
<font size="3" color="#888888" face="serif">-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt </font><br>
<font size="3" color="#888888" face="serif">Nicira, Inc: </font><a href="http://www.nicira.com/" target="_blank"><font size="3" color="#0000FF" face="serif"><u>www.nicira.com</u></font></a><br>
<font size="3" color="#888888" face="serif">twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~</font><br>
<br>
<font size="3" face="serif"><br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank"><font size="3" color="#0000FF" face="serif"><u>OpenStack-dev@lists.openstack.org</u></font></a><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="#0000FF" face="serif"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="serif"><br>
</font></ul>
<tt><font size="2">_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</body></html>