Open Stack

You're right in that there exists an association between a request and a tenant -- but that's not the defining relationship. A tenant is at it's core simply a container that holds a collection of resources.  That's why it makes sense to be in a URI.  The idea is to allow a way of organizing resources  as a means of providing an abstraction between the OpenStack implementation and someone who is operating an OpenStack deployment (the operator).

An operator may map one or more tenants to a project, an account, an identity, a customer, whatever.

Now a request may have permission to access one or more tenants -- and I think that's where a lot of the confusion lies.

I did a writeup for this a bit back you can find it here: https://github.com/RackerWilliams/multi-tenant-accounting/blob/master/tenants.pdf

-jOrGe W.


On Nov 1, 2012, at 2:47 PM, Gabriel Hurley wrote:

IMHO the current tenant (or theoretically tenants) associated with a request is contextual to the request, not an inherent part of the RESTful endpoint. That’s a complicated way of saying that I don’t think tenant IDs belong in any URL except Keystone’s /tenants/ urlspace. There are lots of valid ways to pass the tenant ID in a contextual manner, a query parameter being one, a header being another. Putting it into the URL path only complicates things and (in some cases currently) is redundant.

-          Gabriel

From: heckj [mailto:heckj at mac.com]
Sent: Thursday, November 01, 2012 12:29 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs

Hey Peter,

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.

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.

Needless to say, your feedback on that topic would be nice as it related to the Quantum 2.0 API.

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)


-joe

On Nov 1, 2012, at 12:15 PM, "Mellquist, Peter" <peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>> wrote:
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} / ...  www.api.openstack.org<http://www.api.openstack.org/>

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
/v1.0/…
For cross tenant access, when roles allow so, Quantum 2.0 allows specifying tenant_id as a query parameter, ‘? tenant_id=XXX.’

Does the Quantum 2.0 API work in terms of handling multi-tenant resource access? YES
Is the Quantum 2.0 API consistent with existing Openstack APIs in regard to tenant resource access? NO

Openstack API Community Questions:
Does consistency across Openstack APIs in regard to tenant based resource access matter?
Does this impact developers, direct REST usage or those using language bindings / libraries?

Thank You,
Peter Mellquist
Hewlett Packard Company

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121101/12064d10/attachment.html>