[openstack-dev] [nova] Future of the Nova API

Sean Dague sean at dague.net
Thu Feb 27 17:02:45 UTC 2014


On 02/27/2014 11:05 AM, Dan Smith wrote:
>> Sure, but that's still functionally equivalent to using the /v2 prefix.
>>  So we could chuck the current /v3 code and do:
>>
>> /v2: Current thing
>> /v3: invalid, not supported
>> /v4: added simple task return for server create
>> /v5: added the event extension
>> /v6: added a new event for cinder to the event extension
>>
>> and it would be equivalent.
> 
> Yep, sure. This seems more likely to confuse people or clients to me,
> but if that's how we decided to do it, then that's fine. The approach to
> _what_ we version is my concern.
> 
>> And arguably, anything that is a pure "add" could get away with either a
>> minor version or not touching the version at all.  Only "remove" or
>> "modify" should have the potential to break a properly-written application.
> 
> Totally agree!

Basically agree, I just think we need to realize "properly-written
application" might not be the majority.

But I think as was said previously, the conversion to objects inside of
Nova means we're fundamentally changing the validation anyway, because
the content isn't going all the way down to the database any more.

I do think client headers instead of urls have some pragmatic approach
here that is very attractive. Will definitely need a good chunk of
plumbing to support that in a sane way in the tree that keeps the
overhead from a review perspective low.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/a2ce12b5/attachment.pgp>


More information about the OpenStack-dev mailing list