[openstack-dev] tenant or project

Dolph Mathews dolph.mathews at gmail.com
Sat Nov 23 22:09:27 UTC 2013


On Sat, Nov 23, 2013 at 2:27 PM, Caitlin Bestler <
caitlin.bestler at nexenta.com> wrote:

>
>
> On November 23, 2013 4:09:49 AM Christopher Yeoh <cbkyeoh at gmail.com>
> wrote:
>
>> Hi,
>>
>> So in the past we've used both tenant and project to refer to the same
>> thing and I think its been a source of confusion for people new to
>> OpenStack. In the Nova code we use both, but at least for the API we've
>> been trying to consistently present to the client tenant (which is the
>> majority usage) rather than project.
>> And then Russell pointed out in https://review.openstack.org/#/c/57612/
>> that the Keystone uses project in the Keystone V3 API rather than
>> tenant. http://api.openstack.org/api-ref-identity.html#identity-v3
>>
>> I think that we should be consistent across the openstack projects.
>> From a very quick look at the core openstack projects I think that they
>> mostly use tenant at the moment rather than project.
>>
>> Does this change in Keystone nomenclature signify that we all should be
>> moving to use project rather than tenant in the future (its not
>> too late to do a big a search and replace for the Nova V3 API). And is
>> the plan for Keystone python client to also change to project rather
>> than tenant?
>>
>>
> The advantage of "Tenant" over "project" is that it is far more
> intuitively obvious
> that resources and users belong to a single tenant than it is that they
> belong to
> a single project.
>

You're making a couple assertions here I'd like to discuss individually...

1) it is more intuitive for resources to belong to a single tenant than it
is to belong to a single project

Do you have any justification for this? I personally don't find this more
intuitive at all, but it's certainly subject. I frequently create new
projects to play around with compute instances, etc, and delete the project
when I'm done. The term "project" fits that really well. If we're using the
term "tenant" in this example, it sounds like a I have to provide new
billing information every time I want to goof around, which is not
appealing at all.

- it is more intuitive for user to "belong to" a single tenant than it is
to belong to a single project

First of all, I absolutely despise the phrasing "users belong to tenants"
because it's both vague and wrong. Projects do not own or belong to users.
Users do not own or belong to projects. One identity can hold explicit
authorization in one or more projects via role assignments, group
membership, etc. It's a many-to-many relationship. The distinction between
"tenant" and "project" here is entirely inconsequential because the
statement being made is fundamentally flawed to begin with.


>
> Companies that are the customers of data centers are likely to have many
> "projects", and want their employees to have access to multiple projects.
>

++


> I think we are better off with a label that creates a clear expectation of
> one-bill-payer equals one-tenant.
>

This seems to contradict your previous statement entirely. Alternatively,
you could have "one-bill-payer equals one-domain," where each domain
contains multiple cloud projects with distinct sets of cloud resources all
being aggregated together for billing purposes. As a customer of a data
center, I might be running production, staging, continuous build, and
development environments all as separate tenants/projects. Why would you
want my billing information 100 times a month?


>
> All the data is far simpler with that rule.


What data is simpler in what way with what rule?


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



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131123/9331434c/attachment.html>


More information about the OpenStack-dev mailing list