Open Stack

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.