Added this to the agenda of next team meeting [1]. I would like to ask clarification for " the community are discussing to using Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could anyone provide more information about that?
Best regards, Hongbin > -----Original Message----- > From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com] > Sent: July-28-16 10:52 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Magnum] Microversioning implementation > > > 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 __________________________________________________________________________ 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