On Wed, Nov 27, 2013 at 8:12 AM, Steven Hardy <sha...@redhat.com> wrote:
> On Tue, Nov 26, 2013 at 10:17:56PM +1030, Christopher Yeoh wrote: > > On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco <fla...@redhat.com> > wrote: > > > On 24/11/13 12:47 -0500, Doug Hellmann wrote: > > > > > >> 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). > > >> > > > > > > And, FWIW, Marconi uses project as well. > > > > > > > > Well project seems to be the way everyone is heading long term. So we'll > > do this for the Nova > > V3 API. As others have mentioned, I think the most important this is > that > > we all end up using > > the same terminology (though with the long life of APIs we're stuck with > > the both for a few years > > at least). > > So, Heat has some work to do as we're still using tenant in various places. > > However, I've been thinking, why do the APIs requests have to contain the > project ID at all? Isn't that something we derive from the token in > auth_token (setting X-Project-Id, which we use to set the project in the > request context)? > +1 > > Maybe I'm missing something obvious, but at the moment, when you create a > heat stack, you specify the tenant ID three times, once in the path, once > in the request body, and again in the context. I'm wondering why, and if > we can kill the first two? > 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. > > Clearly this is different for keystone, where the top level of request > granularity is Domain not Project, but for all other services, every > request is scoped to a Project is it not? > > Steve > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
