<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hey Peter,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Needless to say, your feedback on that topic would be nice as it related to the Quantum 2.0 API.</div><div><br></div><div>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)</div><div><br></div><div><br></div><div>-joe</div><div><br><div><div>On Nov 1, 2012, at 12:15 PM, "Mellquist, Peter" <<a href="mailto:peter.mellquist@hp.com">peter.mellquist@hp.com</a>> wrote:</div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; 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/" style="color: purple; text-decoration: underline; ">www.api.openstack.org</a><o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; 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<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">/v1.0/…<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; 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.’<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Does the Quantum 2.0 API work in terms of handling multi-tenant resource access? YES<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Is the Quantum 2.0 API consistent with existing Openstack APIs in regard to tenant resource access? NO<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Openstack API Community Questions:<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Does consistency across Openstack APIs in regard to tenant based resource access matter?<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Does this impact developers, direct REST usage or those using language bindings / libraries?<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Thank You,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Peter Mellquist<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Hewlett Packard Company<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" style="color: purple; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="color: purple; text-decoration: underline; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></body></html>