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

Sean Dague sean at dague.net
Mon Mar 23 11:14:37 UTC 2015

On 03/21/2015 01:21 AM, Chris Friesen wrote:
> Hi,
> 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.

No, this is a specific feature of microversions. The promise of
interoperability between OpenStack instances is completely broken by
vendor extensions in APIs. The Nova team specifically wants out of that

That was a big part of this whole transition.


Sean Dague

More information about the OpenStack-dev mailing list