<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 8:12 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Nov 26, 2013 at 10:17:56PM +1030, Christopher Yeoh wrote:<br>
> On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br>
> > On 24/11/13 12:47 -0500, Doug Hellmann wrote:<br>
> ><br>
> >> On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg <<a href="mailto:m@metacloud.com">m@metacloud.com</a>><br>
> >> wrote:<br>
> >><br>
> >>    In all honesty it doesn't matter which term we go with.  As long as we<br>
> >> are<br>
> >>    consistent and define the meaning.  I think we can argue intuitive vs<br>
> >>    non-intuitive in this case unto the ground.  I prefer "project" to<br>
> >> tenant,<br>
> >>    but beyond being a bit of an "overloaded" term, I really don't think<br>
> >> anyone<br>
> >>    will really notice one way or another as long as everything is using<br>
> >> the<br>
> >>    same terminology.  We could call it "grouping-of-openstack-things" if<br>
> >> we<br>
> >>    wanted to (though I might have to pull some hair out if we go to that<br>
> >>    terminology).      However, with all that in mind, we have made the<br>
> >> choice to move toward<br>
> >>    project (horizon, keystone, OSC, keystoneclient) and have some momentum<br>
> >>    behind that push (plus newer projects already use the project<br>
> >>    nomenclature).   Making a change back to tenant might prove a worse UX<br>
> >> than<br>
> >>    moving everything else in line (nova I think is the one real major<br>
> >> hurdle<br>
> >>    to get converted over, and deprecation of keystone v2 API).<br>
> >><br>
> >> FWIW, ceilometer also uses project in our API (although some of our docs<br>
> >> use<br>
> >> the terms interchangeably).<br>
> >><br>
> ><br>
> > And, FWIW, Marconi uses project as well.<br>
> ><br>
> ><br>
> Well project seems to be the way everyone is heading long term.  So we'll<br>
> do this for the Nova<br>
> V3 API.  As others have mentioned, I think the most important this is that<br>
> we all end up using<br>
> the same terminology (though with the long life of APIs we're stuck with<br>
> the both for a few years<br>
> at least).<br>
<br>
</div></div>So, Heat has some work to do as we're still using tenant in various places.<br>
<br>
However, I've been thinking, why do the APIs requests have to contain the<br>
project ID at all?  Isn't that something we derive from the token in<br>
auth_token (setting X-Project-Id, which we use to set the project in the<br>
request context)?<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe I'm missing something obvious, but at the moment, when you create a<br>
heat stack, you specify the tenant ID three times, once in the path, once<br>
in the request body, and again in the context.  I'm wondering why, and if<br>
we can kill the first two?<br></blockquote><div><br></div><div>Unless they have different reasons for being, stick with the one in the request context. Users shouldn't have to care about multi-tenancy once they've obtained a scoped token, it should just happen.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Clearly this is different for keystone, where the top level of request<br>
granularity is Domain not Project, but for all other services, every<br>
request is scoped to a Project is it not?<br>
<br>
Steve<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>