Open Stack

In all honesty it doesn't matter which term we go with.  As long as we are
consistent and define the meaning.  I think we can argue intuitive vs
non-intuitive in this case unto the ground.  I prefer "project" to tenant,
but beyond being a bit of an "overloaded" term, I really don't think anyone
will really notice one way or another as long as everything is using the
same terminology.  We could call it "grouping-of-openstack-things" if we
wanted to (though I might have to pull some hair out if we go to that
terminology).

However, with all that in mind, we have made the choice to move toward
project (horizon, keystone, OSC, keystoneclient) and have some momentum
behind that push (plus newer projects already use the project
nomenclature).   Making a change back to tenant might prove a worse UX than
moving everything else in line (nova I think is the one real major hurdle
to get converted over, and deprecation of keystone v2 API).

Cheers,
--Morgan Fainberg


On Saturday, November 23, 2013, Caitlin Bestler wrote:

>  I have seen several people request that their users be members of two
> "projects" and that they be allow to publish objects that are "Shared" by
> multiple "projects".
>
> For some reason the people who request these complex data constructions
> always prefer to call the enclosing entity a "project". I have not heard
> such a request for multi-tenant objects and/or users.
>
> The important point is that the "mix and match" approach actually creates
> complex objects where it is difficult to determine who has the right to
> delete them, modify them, change who has access to them, etc. The far
> simpler rule
> is that all objects/resources have a single owner, whether that owner is
> called a "project" or a "tenant".
>
> The term "project", in common english usage, does not have any semantics
> implying exclusivity. Indeed we have "Cross project teams" and resources
> are commonly shared by multiple projects within one company.
>
> The fact that "projects" are typically things *within* a company is
> exactly why it is a poor term for the outermost enclosure of resources.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131123/ca830d81/attachment.html>