Open Stack

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

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.

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

DH


On Thu, Nov 8, 2012 at 9:54 PM, Juergen Brendel (jbrendel) <
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]
> > Sent: Friday, November 09, 2012 8:21 AM
> > To: 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121110/49b69835/attachment.html>