Open Stack

On Fri, Nov 9, 2012 at 6:00 PM, David Hadas <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> 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
>>
>
>
> _______________________________________________
> 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/20121109/d7cbc73d/attachment.html>