I agree with Eugene that the tenant_id is not necessary in the URI.<div>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!</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div><div>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.</div>
<div><br></div><div>Salvatore</div><div><br><div class="gmail_quote">On 2 November 2012 06:04, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Folks, <div><br></div><div>Let me add my 2c to this discussion.</div><div><br></div><div>Objects in Quantum could be identified by their Id, so why specify tenant_id+object_id in URL when object_id is sufficient?</div>
<div>
If we're talking about authorization then keystone middleware adds header with tenant_id allowing to make authorization decision.</div><div>If we're talking about cross tenant access, e.g. when one tenant accesses resource created by another, that implies that there is: </div>
<div>- API for creating/listing such shared resources</div><div>- each resource could still be accessed by ID</div><div>- 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,</div><div>Eugene.<div><div class="h5"><br><br><div class="gmail_quote">On Fri, Nov 2, 2012 at 2:30 AM, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 :) <br>
<div><br></div><div>Dan</div><div><br></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Thu, Nov 1, 2012 at 12:53 PM, Mellquist, Peter <span dir="ltr"><<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks Joe.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Peter.<u></u><u></u></span></p><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> heckj [mailto:<a href="mailto:heckj@mac.com" target="_blank">heckj@mac.com</a>]
<br>
<b>Sent:</b> Thursday, November 01, 2012 12:29 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div><p class="MsoNormal">Hey Peter,<u></u><u></u></p><div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Needless to say, your feedback on that topic would be nice as it related to the Quantum 2.0 API.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-joe<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Nov 1, 2012, at 12:15 PM, "Mellquist, Peter" <<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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} / ... <a href="http://www.api.openstack.org/" target="_blank"><span style="color:purple">www.api.openstack.org</span></a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">/v1.0/…<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">For cross tenant access, when roles allow so, Quantum 2.0 allows specifying tenant_id as a query parameter, ‘? tenant_id=XXX.’<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Does the Quantum 2.0 API work in terms of handling multi-tenant resource access? YES<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Is the Quantum 2.0 API consistent with existing Openstack APIs in regard to tenant resource access? NO<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Openstack API Community Questions:<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Does consistency across Openstack APIs in regard to tenant based resource access matter?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Does this impact developers, direct REST usage or those using language bindings / libraries?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thank You,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Peter Mellquist<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Hewlett Packard Company<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank"><span style="color:purple">OpenStack-dev@lists.openstack.org</span></a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><span style="color:purple">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></a><u></u><u></u></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>