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. (https://review.openstack.org/__#/c/84695/19/specs/juno/v2-on-__v3-api.rst <https://review.openstack.org/#/c/84695/19/specs/juno/v2-on-v3-api.rst>) But finally, those implementations was considered too complex. So I'm try to find out more simple implementation and solution for micro-version. I wrote down some ideas as blog post at: http://soulxu.github.io/blog/__2014/09/12/one-option-for-__nova-api/ <http://soulxu.github.io/blog/2014/09/12/one-option-for-nova-api/> 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! Thanks Alex 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 purpose. 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:
http://docs.oscomputevnext.apiary.io/ -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
