Open Stack

-----Original Message-----
From: John Garbutt <john at johngarbutt.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: February 22, 2016 at 12:53:49
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [api][all] api variation release by release

> On 13 January 2016 at 14:28, Matt Riedemann 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.

Further, JSON home is an abandoned spec that hasn't been completed or really tested by very many (if any) production APIs. It is an option, but if we want to use it, I'd suggest we all become more involved in the IETF working groups to make it an actual standard.

--  
Ian Cordasco