<div dir="ltr">Hi, <br><br>Although this discussion has started about Quantum, it seems that it had widen to suggest that it is a good idea to remove tenant_id in openstack as a whole. Let me try and suggest why this is not a good idea, hopefully also highlighting some aspects that I am not sure are covered by the Quantum tenant-less URLs. <br>
<br>There are three assumptions made by some of the writers above which seem to not consider openstack as a whole:<br><br>1. It is assumed that there is only one identity system for the entire cloud, while there may be more than one.<br>
2. It is assumed that URIs of two objects belonging to two different tenants differ even when one removes the tenant_id, while this is not the case in openstack as a whole.<br>3. It is assumed that a tenant may only access its own resources (or public ones). While this is inline with what I perceive as 'a tenant', others in openstack use the term tenant to say other things and expect keystone to control the sharing between tenants. This is still being debated and worked on in keystone.  <br>
<br>As for 1<br>Support for multiple identity services (could be same or different types) in a cloud requires that the claimed identity of the tenant (or at least the identity of the identity service :)  be known prior to the identity service being approached... - i.e. this information needs to be supplied by the client (either as a header or in the URI). We can rely on keystone to supply the authenticated tenant identity but we still need a claimed tenant identity to be sent by the client somehow (e.g. via the URI).<br>
<br>As for 2<br>It is common to allow users to choose the names of resources they use, as long as this name is unique under a given namespace. In fact, this is the standard way things are done (when a client put an object, it also determines its name...). For example in Swift, a user decides the name of his object inside his container by using a PUT and indicating the container URI. The user also choose  the name of the container inside its account by using PUT and indicating the account URI. <br>
This namespace approach leads to a unique resource name which may be entirely under the control of the user. <br>(This approach is helpful to those of us that likes to use meaningful URIs and prefer <br>    <a href="http://movies.com/Action/TheMatrix1">http://movies.com/Action/TheMatrix1</a> over <br>
    <a href="http://89372984732/ae834b3443c213/23232bc232309093cba">http://89372984732/ae834b3443c213/23232bc232309093cba</a>).<br>and is used by Swift today. Removing the tenant_id would result in no way for the Swift server to identify between /mycontainer/myobject of two tenants.<br>
<br>As for 3<br>The restrictive assumption of Quantum v2, having either private or public resources is not applicable to openstack as a whole. One way to approach this is to solve this mess inside keystone, but this should go in another thread :) <br>
<br>Bottom line is that we can have authentication and authorization based on headers rather than the URI, but it is important to preserve the ability to create separate per-tenant name-spaces that do not rely on the resource URI to be supplied by the service. The natural way to do that is to keep tenant_id as part of the URI. <br>
Otherwise the server would needs to concatenate the authenticated tenant_id, provided by the identity service with whatever the URI is, in order to reach a unique id of a resource... :/<br><br>DH<br><br><br>On Thu, Nov 8, 2012 at 9:54 PM, Juergen Brendel (jbrendel) <span dir="ltr"><<a href="mailto:jbrendel@cisco.com" target="_blank">jbrendel@cisco.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From a purely RESTful standpoint, no tenant ID is needed as long as the<br>
URI remains unique to the resource. So, as long as the server never<br>
has to return different (tenant specific) things for the same URL then<br>
we don't need a tenant ID for anything. If the remainder of the URL<br>
is unique to a particular tenant-specific resource, that's good enough.<br>
<br>
For example, don't let the URI "/foo/bar" return one thing for one tenant<br>
and another for another tenant. Not good. But if that situation doesn't<br>
occur (maybe because there's always a unique resource ID at the end of the<br>
URI) then we don't need the tenant ID.<br>
<br>
In general, though, I noticed that there is a lot of emphasis on various<br>
URI patterns (what should and should not go into a URI), while ideally,<br>
the actual pattern or content of the URI should not matter at all. Clients<br>
should not have to know about how to construct URIs, they should just be<br>
able to follow links to unique resources. And as long as that is the case,<br>
who cares what's in the URI?<br>
<br>
But I guess that's a topic for a different discussion?<br>
<span class="HOEnZb"><font color="#888888"><br>
Juergen<br>
</font></span><div class="im HOEnZb"><br>
<br>
> -----Original Message-----<br>
> From: Jay Pipes [mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
> Sent: Friday, November 09, 2012 8:21 AM<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Subject: Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API<br>
> URLs and Quatum 2.0 APIs<br>
><br>
</div><div class="HOEnZb"><div class="h5">> On 11/02/2012 06:58 PM, Vishvananda Ishaya wrote:<br>
> > FWIW i think tenant_id in the uri is useless and I will be proposing<br>
> to remove it in the next version of the nova api. Glance doesn't have it<br>
> either.<br>
><br>
> Precisely my view as well.<br>
><br>
> -jay<br>
><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>