Tenant vs Project

[justinsb]

Hoping we can side-step the huge can of worms here...

There's been flip-flopping over whether it's called a "tenant" or a "project".

In the Identity V3 API, it is officially a project.

I'm to blame here for proposing a patch which included TenantName, but should we call it TenantName or ProjectName?

I think we should call it "Project", because (1) it makes more sense to humans and (2) it is the V3 word. Even if it currently maps to something in the V2 API called "tenant" :-)

I think everything is new enough that we can easily switch now without needing a compatibility shim.

[sam-falvo]

On Mon, Sep 2, 2013 at 11:01 AM, Justin Santa Barbara < notifications@github.com> wrote:

I think we should call it "Project", because (1) it makes more sense to humans and (2) it is the V3 word. Even if it currently maps to something in the V2 API called "tenant" :-)

Is there a summary of V2 to V3 differences anywhere? When I last checked (admittedly about a month ago), no such executive summary existed.

Concerning tenant vs project, I'm not sure I'm happy with either one. Can you point me to any discussion threads on why they changed the name? According to this site, http://docs.openstack.org/trunk/openstack-compute/admin/content/users-and-projects.html, it looks like tenant ID is the new name, not the old. I'm pretty well confused at this point!

Thanks!

Samuel A. Falvo II

[justinsb]

I think that's out of date. I think in V1 it was project, in V2 it was tenant, and in V3 it is project. I haven't found any documentation as to why though.

Here's the Identity V3 API: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md

There's a summary of "what's new", but most importantly: "Tenants" are now known as "projects"

I personally think project is a much more understandable name than tenant. Really, I don't think it matters much though, as long as we don't ever change.

If we're happy to call it tenant, even if V3 calls it a project, and V4 calls it a projectenant, that's fine with me. If we can come up with a neutral third name, that's fine with me as well (but I suspect that'll be even harder).

[gecampbell]

I can give you a little background. When NASA developed Nova, it was obviously being used for multiple projects internally, hence the project_id identifier. When OpenStack got it, it was realized that the "project" terminology didn't really work for a public cloud, so they changed to the "tenant" nomenclature. The next stage in the evolution was the move to hybrid/private clouds, for which "project" is actually more applicable.

IMHO it's confusing both ways; just stay in sync with OpenStack/Keystone.

Glen Campbell, Manager Rackspace Developer Relations Group (DRG) http://developer.rackspace.com • @glenc

From: Justin Santa Barbara notifications@github.com<mailto:notifications@github.com> Reply-To: rackspace/gophercloud reply@reply.github.com<mailto:reply@reply.github.com> Date: Tuesday, September 3, 2013 1:14 PM To: rackspace/gophercloud gophercloud@noreply.github.com<mailto:gophercloud@noreply.github.com> Subject: Re: [gophercloud] Tenant vs Project (#88)

I think that's out of date. I think in V1 it was project, in V2 it was tenant, and in V3 it is project. I haven't found any documentation as to why though.

Here's the Identity V3 API: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md

There's a summary of "what's new", but most importantly: "Tenants" are now known as "projects"

I personally think project is a much more understandable name than tenant. Really, I don't think it matters much though, as long as we don't ever change.

If we're happy to call it tenant, even if V3 calls it a project, and V4 calls it a projectenant, that's fine with me. If we can come up with a neutral third name, that's fine with me as well (but I suspect that'll be even harder).

— Reply to this email directly or view it on GitHubhttps://github.com/rackspace/gophercloud/issues/88#issuecomment-23734628.

[sam-falvo]

On Tue, Sep 3, 2013 at 11:22 AM, Glen Campbell notifications@github.comwrote:

IMHO it's confusing both ways; just stay in sync with OpenStack/Keystone.

To stay in sync with Keystone, we need to have a separate Authentication API for the V3 endpoint, as distinct from the V2 endpoint.

Let me do some reading and I'll update with a decision (or at least continued discussion) shortly.

[justinsb]

I think a good API binding shields the user from the underlying API breakage.

It's absolutely not cool that the Identity API keeps changing, but we shouldn't break Gophercloud's API unless we absolutely have to.

[sam-falvo]

On Tue, Sep 3, 2013 at 11:35 AM, Justin Santa Barbara < notifications@github.com> wrote:

I think a good API binding shields the user from the underlying API breakage.

It's absolutely not cool that the Identity API keeps changing, but we shouldn't break Gophercloud's API unless we absolutely have to.

Totally. I'm wondering if we have some hidden opportunities that AuthOptions avails to us. E.g., if we specify a TenantId, it resorts to using V2 API bindings, but if ProjectId, to use V3. And if neither are specified, the most recent API available would be used?

Samuel A. Falvo II

[justinsb]

There shouldn't be a difference between using the V2 and V3 APIs, at least for the case of authenticating a username/password, then pick a project/tenant. We should use whatever the server supports. If it supports both, then I guess we should use the newer one (?). Although - for now - I think it's fine to just support V2.

I think our goal should be that when V3 is required on servers, Gophercloud clients should continue to work. Everything else flows from that, IMHO.

[justinsb]

PS So I think we're in agreement, but I don't think we should have magic switches like 'TenantId' vs 'ProjectId', because that will require code changes to Gophercloud's users. If someone really wants to specify they want to force the V2 or V3 API, that should probably be an optional flag when constructing the client instance.

[al-maisan]

On 09/03/2013 08:35 PM, Justin Santa Barbara wrote:

I think a good API binding shields the user from the underlying API breakage.

It's absolutely not cool that the Identity API keeps changing, but we shouldn't break Gophercloud's API unless we absolutely have to. I agree. In order to do so it might be easier to pick a name that's neither tenant nor project though. Organisation? User group?

Best regards/Mit freundlichen Grüßen

Muharem Hrnjadovic muharem@lbox.cc // (public key id : B2BBFCFC)

[sam-falvo]

On Wed, Sep 4, 2013 at 2:00 AM, Muharem Hrnjadovic <notifications@github.com

wrote:

On 09/03/2013 08:35 PM, Justin Santa Barbara wrote:

I think a good API binding shields the user from the underlying API breakage.

It's absolutely not cool that the Identity API keeps changing, but we shouldn't break Gophercloud's API unless we absolutely have to. I agree. In order to do so it might be easier to pick a name that's neither tenant nor project though. Organisation? User group?

How about "division" or "department"?

Samuel A. Falvo II

[markpeek]

I've been thinking about this and believe that departing from existing terminology is worse than picking one over the other. In other words, someone using the api needs to understand how to map their view of the underlying terminology to the api implementation. If anything you could always resort to having both tenant and project exposed in the api but make them mutually exclusive. Then let gophercloud figure out how to map them correctly or give errors back to the user.

[al-maisan]

On 09/06/2013 06:34 AM, Mark Peek wrote:

I've been thinking about this and believe that departing from existing terminology is worse than picking one over the other. In other words, someone using the api needs to understand how to map their view of the underlying terminology to the api implementation. If anything you could always resort to having both tenant and project exposed in the api but make them mutually exclusive. Then let gophercloud figure out how to map them correctly or give errors back to the user. Hmm .. I am not sure, always found both "tenant" and "project" to be contrived.

Why not use a term like "organisation" or "user group" that's clear and well established in the IT domain?

Best regards/Mit freundlichen Grüßen

Muharem Hrnjadovic muharem@lbox.cc // (public key id : B2BBFCFC)

[jamiehannaford]

Although I've never liked tenant, I don't see any problem with project. It seems like a sensible and meaningful word to describe well, projects, that users work on. A reminder of version 3 nomenclature:

A user, that is optionally part of a group, belongs to a domain and works on lots of projects. The domain is the top-level entity that controls groups and projects. To call a project an organization or division therefore seems confusing because you already have a domain for that. I think they might be leaning towards a more open-source picture where a project is a pool of resources that lots of people work on. To quote their docs:

Users, however, can be associated with multiple projects by granting roles to the user on a project (including projects owned by other domains).

[stackedsax]

I'm with Mark. Creating more terminology isn't the way to go. There are already two choices, we don't need to introduce a third.

.:alex:.

On Fri, Sep 6, 2013 at 1:01 AM, Jamie Hannaford notifications@github.comwrote:

Although I've never liked tenant, I don't see any problem with project. It seems like a sensible and meaningful word to describe well, projects, that users work on. A reminder of version 3 nomenclature:

A user, that is optionally part of a group, belongs to a domain and works on lots of projects. The domain is the top-level entity that controls groups and projects. To call a project an organization or divisiontherefore seems confusing because you already have a domain for that. I think they might be leaning towards a more open-source picture where a project is a pool of resources that lots of people work on. To quote their docs:

Users, however, can be associated with multiple projects by granting roles to the user on a project (including projects owned by other domains).

— Reply to this email directly or view it on GitHubhttps://github.com/rackspace/gophercloud/issues/88#issuecomment-23924823 .

[sam-falvo]

On Fri, Sep 6, 2013 at 8:43 AM, stackedsax notifications@github.com wrote:

I'm with Mark. Creating more terminology isn't the way to go. There are already two choices, we don't need to introduce a third.

So, we have 2 people in favor of using project, 1 in favor of neither project nor tenant, and 0 in favor of tenant. Unless this balance changes by Monday (unless we vote to move the deadline), project it shall be. :-)

Samuel A. Falvo II

[sam-falvo]

No objections heard. Project it will be going forward.