Open Stack

OK. My replies are inline.

> -----Original Message-----
> From: Grant, Jaycen V [mailto:jaycen.v.grant at 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.lu at huawei.com]
> Sent: Thursday, July 28, 2016 11:10 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at 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.grant at 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-
> > request at 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-
> request at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev