Open Stack

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
>     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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev