[openstack-dev] [heat] Is it time for a v2 Heat API?

Steven Hardy shardy at redhat.com
Wed Nov 27 17:30:28 UTC 2013

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

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.


More information about the OpenStack-dev mailing list