Open Stack

On 11/09/2012 07:00 PM, David Hadas wrote:
> Hi,
> 
> 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.
> 
> There are three assumptions made by some of the writers above which seem
> to not consider openstack as a whole:
> 
> 1. It is assumed that there is only one identity system for the entire
> cloud, while there may be more than one.

This is irrelevant to the discussion IMHO.

> 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.

Could you show us an example of this from one of the OpenStack APIs. I
cannot think of one.

> 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.

No, this is not the case with any of the OpenStack services, AFAIK.
Keystone doesn't control the sharing of things between tenants -- ever.
Each individual service controls the sharing of things between tenants
differently. No OpenStack service calls out to Keystone for
authorization requests. It only uses Keystone for authentication
requests. This is a deliberate decision to avoid costly lookups into
Keystone for oft-made actions against resources. Keystone would become a
giant system bottleneck if this were the case.

<snip>

> 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.
> 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... :/

My problem with just shoving %(tenant_id)s in the URIs at the root of
the URL is that there is no description as to what the ID is a resource of.

For example, somebody looking at the URI:

http://compute.example.com/v2/4f6e1340-2c61-11e2-81c1-0800200c9a66/servers

really has no clue what the "4f6e1340-2c61-11e2-81c1-0800200c9a66"
refers to. They need to refer to an API spec to understand what it is,
because there is no indicator for what the resource is that
"4f6e1340-2c61-11e2-81c1-0800200c9a66" refers to.

I would not have a problem with URIs structured like so:

http://compute.example.com/v2/tenants/4f6e1340-2c61-11e2-81c1-0800200c9a66/servers

because it is clear that "4f6e1340-2c61-11e2-81c1-0800200c9a66" is a
winnowing identifier for the "tenants" resource, and that "servers" is a
collection owned by that tenant resource.

In the same way that this URI:

http://compute.example.com/v2/servers?tenant_id=4f6e1340-2c61-11e2-81c1-0800200c9a66

Makes it clear as well. The tenant_id is a query parameter winnowing the
results of a search on the servers collection.

I prefer the second URI form over the first because the resource being
requested by the query is actually a collection of servers, not tenants,
and I like to see the eventual resource being returned be the left-most
referred collection in the URI.

This second URI form is also more flexible, since it allows for
cross-tenant queries:

http://compute.example.com/v2/servers?tenant_id=4f6e1340-2c61-11e2-81c1-0800200c9a66&tenant_id=1699ede0-2c62-11e2-81c1-0800200c9a66

Whereas the above is impossible to do with tenant ID just stuck in the
left-most part of the URL.

Best,
-jay

> DH
> 
> 
> On Thu, Nov 8, 2012 at 9:54 PM, Juergen Brendel (jbrendel)
> <jbrendel at cisco.com <mailto:jbrendel at cisco.com>> wrote:
> 
>     From a purely RESTful standpoint, no tenant ID is needed as long as the
>     URI remains unique to the resource. So, as long as the server never
>     has to return different (tenant specific) things for the same URL then
>     we don't need a tenant ID for anything. If the remainder of the URL
>     is unique to a particular tenant-specific resource, that's good enough.
> 
>     For example, don't let the URI "/foo/bar" return one thing for one
>     tenant
>     and another for another tenant. Not good. But if that situation doesn't
>     occur (maybe because there's always a unique resource ID at the end
>     of the
>     URI) then we don't need the tenant ID.
> 
>     In general, though, I noticed that there is a lot of emphasis on various
>     URI patterns (what should and should not go into a URI), while ideally,
>     the actual pattern or content of the URI should not matter at all.
>     Clients
>     should not have to know about how to construct URIs, they should just be
>     able to follow links to unique resources. And as long as that is the
>     case,
>     who cares what's in the URI?
> 
>     But I guess that's a topic for a different discussion?
> 
>     Juergen
> 
> 
>     > -----Original Message-----
>     > From: Jay Pipes [mailto:jaypipes at gmail.com
>     <mailto:jaypipes at gmail.com>]
>     > Sent: Friday, November 09, 2012 8:21 AM
>     > To: openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>
>     > Subject: Re: [openstack-dev] Specifying Tenant-ID in Openstack
>     REST API
>     > URLs and Quatum 2.0 APIs
>     >
>     > On 11/02/2012 06:58 PM, Vishvananda Ishaya wrote:
>     > > FWIW i think tenant_id in the uri is useless and I will be proposing
>     > to remove it in the next version of the nova api. Glance doesn't
>     have it
>     > either.
>     >
>     > Precisely my view as well.
>     >
>     > -jay
>     >
>     > _______________________________________________
>     > 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
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>