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

Monty Taylor mordred at inaugust.com
Sat Mar 21 15:31:21 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.

I would vote that we not make this pleasant or easy for vendors who are
wanting to add a feature to the API. As a person who uses several clouds
daily, I can tell you that a vendor chosing to do that is VERY mean to
users, and provides absolutely no value to anyone, other than allowing
someone to make a divergent "differentiated" fork.

Just don't do it. Seriously. It makes life very difficult for people
trying to consume these things.

The API is not the place for divergence.

More information about the OpenStack-dev mailing list