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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
