Open Stack

On Wed, Nov 27, 2013 at 06:02:27PM +0100, Zane Bitter wrote:
> On 27/11/13 16:27, Steven Hardy wrote:
> >I've raised this BP:
> >
> >https://blueprints.launchpad.net/heat/+spec/v2api
> >
> >And started a WIP wiki page where we can all work on refining what changes
> >need to be made:
> >
> >https://wiki.openstack.org/wiki/Heat/Blueprints/V2API
> 
> The current (v1) API design is based around having the tenant in the
> URL and stack names that are unique per-tenant. So a URL of the
> form:
> 
>     GET /v1/{tenant_id}/stacks/{stack_name}
> 
> uniquely identifies a stack (even though it redirects to a longer
> URL including the stack_id).
> 
> Your proposal on the wiki page retains this URL but removes the tenant ID:
> 
>    GET /v2/stacks/{stack_name}
> 
> This now no longer uniquely identifies a stack, and is therefore not ReST.

Well we still know the tenant ID, because it's a tenant/project scoped
request (keystone auth_token gives us the tenant ID and we set it in the
context).

So in theory we still have all the information we need to uniquely
reference a stack by name, it could just become a query parameter which
filters based on the name:

GET v2/stacks?stack_name=foo

> So if we drop the tenant_id then we should also start addressing
> stacks only by UUID:
> 
>     GET v2/stacks/{stack_id}
> 
> and do lookups by name using stack list or something. However other
> projects do it.

Yes, AFAICT that is what the nova and keystone v3 API's do, keystone does
the name->id lookup in keystoneclient, not sure how nova handles it yet.

Note the wiki is not a proposal, it's just a cut/paste from our API docs
which we can all hack on until it makes sense.  I'll update it to reflect
the above.

> This seems clearly worse than the API we have, but it would at least
> be consistent with other OpenStack projects. For them this API makes
> more sense, because they don't enforce unique names for things in a
> tenant and probably couldn't start if they wanted to. This was IMHO
> a mistake, and one that Heat avoided, but I accept that it's hard to
> escape gravity on this. I, for one, welcome our new UUID overlords.

Lol, well I supposed there are advantages to both.  I'm approaching this
from the perspective of trying to support non project-scoped requests (the
management-api stuff), which is impossible to do properly with the tenant
in the path.

I think consistency accross projects is a good reason to do this, assuming
the way keystone and nova v3 APIs look is the way OpenStack APIs are
headed, which appears to be the case.

Steve