Open Stack

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:



GET https://nova.example.com/servers



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?



Youcef


From: Dolph Mathews [mailto:dolph.mathews at gmail.com]
Sent: Friday, November 09, 2012 6:09 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs


On Fri, Nov 9, 2012 at 6:00 PM, David Hadas <david.hadas at gmail.com<mailto:david.hadas at gmail.com>> 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.

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: "From a purely RESTful standpoint, no tenant ID is needed as long as the URI remains unique to the resource."


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

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?)


As for 1
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).

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?

As for 2
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.
This namespace approach leads to a unique resource name which may be entirely under the control of the user.
(This approach is helpful to those of us that likes to use meaningful URIs and prefer
    http://movies.com/Action/TheMatrix1 over
    http://89372984732/ae834b3443c213/23232bc232309093cba).
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.

Absolutely, that's a great example of tenant-owned resources being reflected by the URI.


As for 3
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 :)

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

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.



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<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/20121110/3a6af76b/attachment.html>