Hongbin & team
Please forget Semantic Versioning API, that should not be done in short
term especially API WG had defined lots
of Microversion API docs, sorry to make confusions.
Of cause that Microversion API is important to OpenStack, and it has
documented well in API WG [1].
For Magnum, I remember that the implementation idea is from ironic [2],
it is simple.
For [3] which comes from Nova is complex because that nova implement
router itself, but Magnum
(Ironic) use pecan. We need to maintain it Magnum as well, also when I
doing some testing, I still
find some unexpected exception if passing bad Microversion, it should
follow API WG.
At last Magnum has very few APIs entry point now,
baymodel.py bay.py certificate.py magnum_services.py
Seen from Ironic, it has bump the version to v1.21 [2] with current
Magnum's microversion's infra
I am okay to go with [3] as long as [3] fellows up with APIWG[1] and
have better testing, I really don't
want to maintain an infra which won't be used frequently.
[1] https://wiki.openstack.org/wiki/VersionDiscovery
[2] https://github.com/openstack/ironic/blob/master/doc/source/webapi/v1.rst
[3]
https://review.openstack.org/#/c/343060/8/magnum/api/controllers/v1/bay.py
On 2016年07月29日 03:19, Hongbin Lu wrote:
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
--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.
__________________________________________________________________________
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
