[openstack-dev] [nova] how to handle vendor-specific API microversions?

Chris Friesen chris.friesen at windriver.com
Tue Mar 24 17:10:47 UTC 2015

On 03/24/2015 07:42 AM, Sean Dague wrote:
> On 03/24/2015 09:11 AM, Jeremy Stanley wrote:
>> On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote:
>>> How would that be expected to work for things where it's
>>> fundamentally just a minor extension to an existing nova API?
>>> (Exposing additional information as part of "nova show", for
>>> example.)
>> Conversely, how do you recommend users of your environment reconcile
>> the difference in nova show output compared to what they get from
>> the other OpenStack environments they're using? How do you propose
>> to address the need for client libraries to cater to your divergent
>> API returning different numbers of parameters for certain methods?

We had been trying to control things properly via the extensions mechanism so 
that the changes could be documented/controlled.

As for clients, if the properties in the response are named, then simply adding 
a new property to a response message body shouldn't be a problem--clients could 
just ignore properties that they don't understand.

> I think these conversations work better in the concrete than the abstract.
> Chris, what additional attributes are you exposing on nova show which
> are critical for your installation? Can we figure out a way to
> generically support whatever that is?

In some cases it might be something that could conceivably go in upstream, but 
hasn't yet.  This might be something as simple as having "nova show" display the 
server group that an instance is in, or it might be a bugfix that hasn't been 
merged upstream yet (like "https://review.openstack.org/#/c/16306" for example) 
or it might be per-instance control over things that upstream currently only 
allows control over at the image/flavor level.  Some of these might take a 
release or two to get merged (and there's no guarantee that they would ever be 
merged) but customers want the functionality in the meantime.

In other cases the change is unlikely to ever be merged upstream, either because 
it's too domain-specific or the solution is messy or even proprietary.


More information about the OpenStack-dev mailing list