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

Chris Friesen chris.friesen at windriver.com
Sat Mar 21 05:21:50 UTC 2015


I've recently been playing around a bit with API microversions and I noticed 
something that may be problematic.

The way microversions are handled, there is a monotonically increasing 
MAX_API_VERSION value in "nova/api/openstack/api_version_request.py".  When you 
want to make a change you bump the minor version number and it's yours. 
End-users can set the microversion number in the request to indicate what they 
support, and all will be well.

The issue is that it doesn't allow for OpenStack providers to add their own 
private microversion(s) to the API.  They can't just bump the microversion 
internally because that will conflict with the next microversion bump upstream 
(which could cause problems when they upgrade).

In terms of how to deal with this, it would be relatively simple to just bump 
the major microversion number at the beginning of each new release.  However, 
that would make it difficult to backport bugfixes/features that use new 
microversions since they might overlap with private microversions.

I think a better solution might be to expand the existing microversion API to 
include a third digit which could be considered a "private" microversion, and 
provide a way to check the third digit separate from the other two.  That way 
providers would have a way to add custom features in a backwards-compatible way 
without worrying about colliding with upstream code.



More information about the OpenStack-dev mailing list