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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
