There has been a discussion around micro versioning implementation going on in
the following patch: https://review.openstack.org/#/c/343060/8 and I was asked
to bring it to the mailing list for further discussion.
Magnum added header support for microversioning according to the Openstack
spec[1] but since we haven’t had any changes yet it was not being used. In the
patch mentioned above I added code that provides infrastructure for
implementing micro versions for our API methods. I took the idea from how Nova
implemented micro versioning and used some of their code modified to work with
Pecan. The basic idea is that you version a method using api_version decorator
as shown below:
@base.Controller.api_version("1.1")
@expose.expose(BayCollection, types.uuid)
def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for version 1.1
@base.Controller.api_version(“1.2”, “1.3")
@expose.expose(BayCollection, types.uuid)
def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for versions 1.2 through 1.3
@base.Controller.api_version("1.4")
@expose.expose(BayCollection, types.uuid)
def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for version 1.4 to latest version
The api_version code takes care of selecting the correct version based on
version requested in the header. It also checks for version overlaps in the
methods and gaps in the method versions.
While working on this Vijendar(working on the first api changes that need api
versioning) and myself, evaluated several other alternatives:
1) Just have each method check the version object and handle the differences.
This was the most basic solution and will work but we were concerned it would
add a lot of duplicate code. We were also concerned it would be messy in the
future as more and more micro versions were added. Each method would now be
responsible for additional checking and more places to change code if there
were overall micro version code changes in the future.
2) Separate pecan controllers for each micro version. When a new micro version
is added a new controller would be created inheriting from the previous version
controller. The new controller would override the modified methods. Routing
changes would be added to make sure that the correct controller was used
depending on the API header. We felt that the api_version decorator was
slightly less complicated and less code overhead on each api version change.
I’d appreciate feedback on whether this is the right way to go or if it would
be better to go to alternative option 1 or 2. Here were some of the concerns by
one of the cores in the code review:
I don't accept this patch, mark it as -2:
Reason:
1. we have already support microversion in our code base, and your propose
(copied from nova) make things complicated.
2. I think you want to support "Support for async bay operations" for you
adding microversion support, right?
I would like suggest you as http://paste.openstack.org/show/543105/ , it
should work for you
3. we don't have too may requirements to bump our microversion (I know you
want to use it in bay-creation async), so we don't want bring much code here
then we need to maintain it later.
4. the community are discussing to using Semantic Versioning(X.Y.Z) [1]
instead of microversion X.Y
[1]http://semver.org/
If you have any questions , please discuss it in mailing list or weekly
meeting.
Eli.
Jaycen Grant
OSIC
[1]
http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html?highlight=microversioning
>>
__________________________________________________________________________
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
