On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg <m...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev