<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg <span dir="ltr"><<a href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font><span style="background-color:rgba(255,255,255,0)">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). </span></font></div>

<div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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). </span></font></div>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">FWIW, ceilometer also uses project in our API (although some of our docs use the terms interchangeably).</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><font><span style="background-color:rgba(255,255,255,0)"><br>Cheers,<br>--Morgan Fainberg</span></font></div><div class="HOEnZb"><div class="h5"><div><span style="background-color:rgba(255,255,255,0)"><br></span></div>
<br>On Saturday, November 23, 2013, Caitlin Bestler  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font-family:sans-serif">
<p>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".</p>
<p>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.</p>
<p>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<br>
is that all objects/resources have a single owner, whether that owner is
called a "project" or a "tenant".</p>
<p>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.</p>
<p>The fact that "projects" are typically things *within* a company is
exactly why it is a poor term for the outermost enclosure of resources.<br>
</p>
</div>

</blockquote>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>