On 09/24/2014 05:26 AM, Kenichi Oomichi wrote:
-----Original Message-----
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Wednesday, September 24, 2014 12:47 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Some ideas for micro-version implementation

On 09/22/2014 04:27 PM, Brant Knudson wrote:
On Fri, Sep 19, 2014 at 1:39 AM, Alex Xu <x...@linux.vnet.ibm.com
<mailto:x...@linux.vnet.ibm.com>> wrote:

     Close to Kilo, it is time to think about what's next for nova API.
     In Kilo, we
     will continue develop the important feature micro-version.

     In previous v2 on v3 propose, it's include some implementations can be
     used for micro-version.
     But finally, those implementations was considered too complex.

     So I'm try to find out more simple implementation and solution for

     I wrote down some ideas as blog post at:

     And for those ideas also already done some POC, you can find out in
     the blog post.

     As discussion in the Nova API meeting, we want to bring it up to
     mail-list to
     discussion. Hope we can get more idea and option from all developers.

     We will appreciate for any comment and suggestion!


Did you consider JSON Home[1] for this? For Juno we've got JSON Home
support in Keystone for Identity v3 (Zaqar was using it already). We
weren't planning to use it for microversioning since we weren't planning
on doing microversioning, but I think JSON Home could be used for this

Using JSON Home, you'd have relationships that include the version, then
the client can check the JSON Home document to see if the server has
support for the relationship the client wants to use.

[1] http://tools.ietf.org/html/draft-nottingham-json-home-03

++ I used JSON-Home extensively in the Compute API blueprint I put
together a few months ago:


vNext seems an interesting idea, I thought the implementation way for Nova
a little. "API Route Discoverability" is a nice design, but a root "/" URL
will conflict on current "list versions" API.
Maybe there would be a workaround.

Completely agreed, Ken'ichi. The "root" URL that returns the JSON-Home doc in the vNext API is actually *after* the version in the URI, though...

So, the JSON-Home doc would be returned from:


Of course, replacing "vNext" with "v4" or "v42" or whatever the "next" major version of the API would be. The real root would still return the versions list as it exists today, with a 302 Multiple Choice.


OpenStack-dev mailing list

Reply via email to