Open Stack

On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg <m at metacloud.com> wrote:

> 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).
>

FWIW, ceilometer also uses project in our API (although some of our docs
use the terms interchangeably).

Doug



>
> 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.
>>
>
> _______________________________________________
> 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/20131124/276d30c1/attachment.html>