<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 23, 2013 at 2:27 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:caitlin.bestler@nexenta.com" target="_blank">caitlin.bestler@nexenta.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
On November 23, 2013 4:09:49 AM Christopher Yeoh <<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
So in the past we've used both tenant and project to refer to the same<br>
thing and I think its been a source of confusion for people new to<br>
OpenStack. In the Nova code we use both, but at least for the API we've<br>
been trying to consistently present to the client tenant (which is the<br>
majority usage) rather than project.<br>
And then Russell pointed out in <a href="https://review.openstack.org/#/c/57612/" target="_blank">https://review.openstack.org/#<u></u>/c/57612/</a><br>
that the Keystone uses project in the Keystone V3 API rather than<br>
tenant. <a href="http://api.openstack.org/api-ref-identity.html#identity-v3" target="_blank">http://api.openstack.org/api-<u></u>ref-identity.html#identity-v3</a><br>
<br>
I think that we should be consistent across the openstack projects.<br>
>From a very quick look at the core openstack projects I think that they<br>
mostly use tenant at the moment rather than project.<br>
<br>
Does this change in Keystone nomenclature signify that we all should be<br>
moving to use project rather than tenant in the future (its not<br>
too late to do a big a search and replace for the Nova V3 API). And is<br>
the plan for Keystone python client to also change to project rather<br>
than tenant?<br>
<br>
</blockquote>
<br></div>
The advantage of "Tenant" over "project" is that it is far more intuitively obvious<br>
that resources and users belong to a single tenant than it is that they belong to<br>
a single project.<br></blockquote><div><br></div><div>You're making a couple assertions here I'd like to discuss individually...</div><div><br></div><div>1) it is more intuitive for resources to belong to a single tenant than it is to belong to a single project</div>
<div><br></div><div>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.</div>
<div><br></div><div>- it is more intuitive for user to "belong to" a single tenant than it is to belong to a single project<br></div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Companies that are the customers of data centers are likely to have many<br>
"projects", and want their employees to have access to multiple projects.<br></blockquote><div><br></div><div>++</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I think we are better off with a label that creates a clear expectation of<br>
one-bill-payer equals one-tenant.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
All the data is far simpler with that rule.</blockquote><div><br></div><div>What data is simpler in what way with what rule?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>