OK. My replies are inline. > -----Original Message----- > From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com] > Sent: July-28-16 2:31 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Magnum] Microversioning implementation > > I was completely unaware of any discussion of Semantic Versioning. > That was brought up by Eli Qiao in the code review, so he might be the > one to point us in the right direction for that. > > Jaycen > > -----Original Message----- > From: Hongbin Lu [mailto:hongbin...@huawei.com] > Sent: Thursday, July 28, 2016 11:10 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Magnum] Microversioning implementation > > 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
[Hongbin Lu] It looks the fundamental difference between the proposed patch (https://review.openstack.org/#/c/343060/8/magnum/api/controllers/v1/bay.py) and the snippet (http://paste.openstack.org/show/543105/) is the usage of a decorator "api_version". The proposed patch implemented the decorator and used it to select the right version while the snippet selected the version inline. I lean to the decorator implementation because it looks clean and seems to effectively reduce duplicated codes. > > 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. [Hongbin Lu] It is hard to forecast how frequent we need to bump the microversion. If we will bump the version frequently, the decorator implementation looks like the right approach. If not, implementing a decorator looks like an over-killed but I doubt if it will incur significant maintenance burden. > > 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=microversionin > > g > > > > >> > > > ______________________________________________________________________ > > _ > > ___ > > 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 > _______________________________________________________________________ > ___ > 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
