Open Stack

On Wed, Nov 27, 2013 at 8:12 AM, Steven Hardy <shardy at 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 <flavio at 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 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).
> > >>
> > >
> > > 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131127/27b29d1e/attachment.html>