<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-06 20:31 GMT+08:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 01/06/2015 06:25 AM, Chen CH Ji wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Based on nova-specs api-microversions.rst<br>
we support following function definition format, but it violate the<br>
hacking rule pep8 F811 because duplicate function definition<br>
we should use #noqa for them , but considering microversion may live for<br>
long time ,<br>
keep adding #noqa may be a little bit ugly, can anyone suggest a good<br>
solution for it ? thanks<br>
<br>
 >   @api_version(min_version='2.1'<u></u>)<br>
 >   def _version_specific_func(self, req, arg1):<br>
 >      pass<br>
 ><br>
 >   @api_version(min_version='2.5'<u></u>)<br>
 >   def _version_specific_func(self, req, arg1):<br>
 >      pass<br>
</blockquote>
<br></span>
Hey Kevin,<br>
<br>
This was actually one of my reservations about the proposed microversioning implementation -- i.e. having functions that are named exactly the same, only decorated with the microversioning notation. It kinda reminds me of the hell of debugging C++ code that uses STL: how does one easily know which method one is in when inside a debugger?<br>
<br>
That said, the only other technique we could try to use would be to not use a decorator and instead have a top-level dispatch function that would inspect the API microversion (only when the API version makes a difference to the output or input of that function) and then dispatch the call to a helper method that had the version in its name.<br>
<br>
So, for instance, let's say you are calling the controller's GET /$tenant/os-hosts method, which happens to get routed to the nova.api.openstack.compute.<u></u>contrib.hosts.HostController.<u></u>index() method. If you wanted to modify the result of that method and the API microversion is at 2.5, you might do something like:<br>
<br>
 def index(self, req):<br>
     req_api_ver = utils.get_max_requested_api_<u></u>version(req)<br>
     if req_api_ver == (2, 5):<br>
         return self.index_2_5(req)<br>
     return self.index_2_1(req)<br>
<br>
 def index_2_5(self, req):<br>
     results = self.index_2_1(req)<br>
     # Replaces 'host' with 'host_name'<br>
     for result in results:<br>
         result['host_name'] = result['host']<br>
         del result['host']<br>
     return results<br>
<br>
 def index_2_1(self, req):<br>
     # Would be a rename of the existing index() method on<br>
     # the controller....<br>
<br>
Another option would be to use something like JSON-patch to determine the difference between two output schemas and automatically translate one to another... but that would be a huge effort.<br></blockquote><div><br></div><div>Just JSON-patch only can resolve multiple-version of request/response, we need handle semantic change also.</div><div><br></div><div>But I still think we need something like JSON-patch, it can avoid add new method only for small request/response changing, like this patch <a href="https://review.openstack.org/#/c/144995/3">https://review.openstack.org/#/c/144995/3</a></div><div> </div><div>I have propose before, we can try mapping the request/response into nova object by json-schema automatically, the nova object will handle the change. When the request/response changed, nothing will change in REST API code. I wrote the POC before <a href="https://github.com/soulxu/nova-v3-api-doc/commits/micro_ver_with_obj_auto_mapping">https://github.com/soulxu/nova-v3-api-doc/commits/micro_ver_with_obj_auto_mapping</a></div><div>This is more easy to maintenance than JSON-patch(thinking about the case of 3.3 patch based on 3.2 patch based on 3.1 patch.....)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
That's the only other way I can think of besides disabling F811, which I really would not recommend, since it's a valuable safeguard against duplicate function names (especially duplicated test methods).<br>
<br>
Best,<br>
-jay<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>