Open Stack

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)?

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?

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