[openstack-dev] [api][all] api variation release by release

John Garbutt john at johngarbutt.com
Mon Feb 22 18:51:55 UTC 2016


On 13 January 2016 at 14:28, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> On 1/13/2016 12:11 AM, joehuang wrote:
>>
>> Thanks for the information, it's good to know the documentation. The
>> further question is whether there is any XML format like document will be
>> published for each release and all core projects, so that other cloud
>> management software can read the changes, and deal with the fields
>> variation.
>>
>> For example, each project will maintain one XML file in its repository to
>> record all API update in each release.
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -----Original Message-----
>> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
>> Sent: Wednesday, January 13, 2016 10:56 AM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [api][all] api variation release by release
>>
>>
>>
>> On 1/12/2016 7:27 PM, joehuang wrote:
>>>
>>> Hello,
>>>
>>> As more and more OpenStack release are deployed in the production
>>> cloud, multiple releases of OpenStack co-located in a cloud is a very
>>> common situation. For example, "Juno" and "Liberty" releases co-exist
>>> in the same cloud.
>>>
>>> Then the cloud management software has to be aware of the API
>>> variation of different releases, and deal with the different field of
>>> object in the request / response. For example, in "Juno", no
>>> "multiattach" field in the "volume" object, but the field presents in
>>> "Liberty".
>>>
>>> Each releases will bring some API changes, it will be very useful that
>>> the API variation will also be publish after each release is
>>> delivered, so that the cloud management software can read and changes
>>> and react accordingly.
>>>
>>> Best Regards
>>>
>>> Chaoyi Huang ( Joe Huang )
>>>
>>>
>>>
>>> ______________________________________________________________________
>>> ____ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Have you heard of this effort going on in multiple projects called
>> microversions? For example, in Nova:
>>
>> http://docs.openstack.org/developer/nova/api_microversion_history.html
>>
>> Nova and Ironic already support microversioned APIs. Cinder and Neutron
>> are working on it I think, and there could be others.
>>
>
> No, there is nothing like that, at least that I've heard of. I don't know
> how you'd model what's changing in the microversions in a language like XML.

You will probably find this summary really interesting:
https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

The idea is people can deploy any commit of Nova in production.
So to work out what is supported you just look at this API:
http://developer.openstack.org/api-ref-compute-v2.1.html#listVersionsv2.1

You can consult the docs to see what that specific version gives you.
Thats still a work in progress, for now we have this:
* http://docs.openstack.org/developer/nova/api_microversion_history.html
* http://developer.openstack.org/api-guide/compute/

There is talk of using JSON home to make some details machine readable.
But its hard to express the semantic changes in a machine readable form.

Does that help?

Thanks,
johnthetubaguy



More information about the OpenStack-dev mailing list