[openstack-dev] [heat] Is it time for a v2 Heat API?
Hi all, Recently we've been skirting around the issue of an API version bump in various reviews, so I thought I'd start a thread where we can discuss the way forward. My view is that we probably should look at creating a v2 API during Icehouse, but we need to discuss what changes make sense, and if we want to attempt adopting pecan/wsme or just clone what we have and modify the interfaces. 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 Feel free to add items to the list at the top so we can capture the various changes folks want. Thoughts? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Is it time for a v2 Heat API?
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.
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.
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.
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Is it time for a v2 Heat API?
On 11/27/2013 12:02 PM, 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.
It would be along with a Vary: X-Project-Id header, no?
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.
++ for this anyway :)
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. Actually, in Nova and other places it's now moving to UNIQUE
CONSTRAINT (name, project, deleted) ;)
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Is it time for a v2 Heat API?
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Is it time for a v2 Heat API?
On 27/11/13 18:16, Jay Pipes wrote:
On 11/27/2013 12:02 PM, Zane Bitter wrote:
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.
It would be along with a Vary: X-Project-Id header, no?
Sure, but the point of HTTP is that a URI addresses exactly one
resource. A resource may have multiple representations and the one
returned can depend on the headers, but a URI should never address more
than one resource.
For example, you could easily imagine a situation where you end up
getting served data for another tenant from a cache somewhere, which
would be Very Bad.
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.
++ for this anyway :)
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. Actually, in Nova and other places it's now moving to UNIQUE
CONSTRAINT (name, project, deleted) ;)
Oh, perfect :) Then we should just keep the tenant_id and wait for
everyone else to circle back around :D
Even better would be if we had the keystone domain (instead of the
tenant id) incorporated into the endpoint in the keystone catalog and
then we could use the tenant^W project *name* in the URL and users would
never have to deal with UUIDs and invisible headers again - your server
is always at /my-project-name/servers/my-server-name. Where you might
expect it to be.
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Is it time for a v2 Heat API?
On 11/27/2013 11:50 AM, Zane Bitter wrote: Even better would be if we had the keystone domain (instead of the tenant id) incorporated into the endpoint in the keystone catalog and then we could use the tenant^W project *name* in the URL and users would never have to deal with UUIDs and invisible headers again - your server is always at /my-project-name/servers/my-server-name. Where you might expect it to be. That sounds way too logical... Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
