<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoPlainText>The problem is with container resources. We cannot guarantee that the same resource URI used by 2 different tenants returns the same result. When tenant 1, issues the command:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>GET <a href="https://nova.example.com/servers">https://nova.example.com/servers</a><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The result is tenant 1 servers, and when tenant 2 does the same thing, it will be tenant 2 servers. Is this a case where the same URI used by 2 different tenants is returning a different result?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Youcef<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><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"'> Dolph Mathews [mailto:dolph.mathews@gmail.com] <br><b>Sent:</b> Friday, November 09, 2012 6:09 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<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>On Fri, Nov 9, 2012 at 6:00 PM, David Hadas <<a href="mailto:david.hadas@gmail.com" target="_blank">david.hadas@gmail.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I don't think anyone is suggesting to completely remove tenant ID's from URLs across OpenStack; I think Juergen Brendel summarized it really well: "<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>From a purely RESTful standpoint, no tenant ID is needed as long as the URI remains unique to the resource."</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal><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. <o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>As a blanket statement, tenants/projects own arbitrary resources in OpenStack, and each service defines what type of resources those are. (I'm not aware of any examples that violate this definition?)<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='margin-bottom:12.0pt'><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).<o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The "claim" can simply be the user's token, obtained from keystone; from that perspective, the tenant supplied by keystone to the underlying service is merely metadata associated with the token. So, I'm not clear one why you need a claimed tenant + authenticated tenant, unless you're expecting them to be different?<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>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" target="_blank">http://movies.com/Action/TheMatrix1</a> over <br> <a href="http://89372984732/ae834b3443c213/23232bc232309093cba" target="_blank">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.<o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Absolutely, that's a great example of tenant-owned resources being reflected by the URI.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal><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... :/<o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm not sure I follow the beginning of this example, but the result is *exactly* what the consensus here wants to avoid: two tenants getting a different result from the same URI.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal><span style='color:#888888'><br><br>DH</span><o:p></o:p></p><div><div><p class=MsoNormal><br><br><br>On Thu, Nov 8, 2012 at 9:54 PM, Juergen Brendel (jbrendel) <<a href="mailto:jbrendel@cisco.com" target="_blank">jbrendel@cisco.com</a>> wrote:<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>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 style='color:#888888'><br>Juergen</span><o:p></o:p></p><div><p class=MsoNormal><br><br>> -----Original Message-----<br>> From: Jay Pipes [mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>]<br>> Sent: Friday, November 09, 2012 8:21 AM<br>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">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>><o:p></o:p></p></div><div><div><p class=MsoNormal>> 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" 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>_______________________________________________<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><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><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><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>