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

2013-11-27 Thread Steven Hardy
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

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

2013-11-27 Thread Zane Bitter
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

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

2013-11-27 Thread Jay Pipes
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:

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

2013-11-27 Thread Steven Hardy
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:

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

2013-11-27 Thread Zane Bitter
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:

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

2013-11-27 Thread Chris Friesen
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