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.
Thoughts?
Chris
__________________________________________________________________________
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
