Open Stack

From: Hongbin Lu <hongbin034 at gmail.com<mailto:hongbin034 at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, March 23, 2015 at 8:37 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient

Hi Madhuri,

Amazing work! I wouldn't concern the code duplication and modularity issue since the codes are generated. However, there is another concern here: if we find a bug/improvement of the generated code, we probably need to modify the generator. The question is if the upstream will accept the modifications? If yes, how fast the patch will go through.

I would prefer to maintain a folk of the generator. By this way, we would have full control of the generated code. Thoughts?

Best practice is to to merge patches upstream unless upstream is really non-responsive.  For an example of something that would be handy to fix – the code generator should be generating pep8 compliant code ;)

The big issue with submitting changes to swagger is swagger is written in erlang – groan.

Regards,
-steve


Thanks,
Hongbin

On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) <stdake at cisco.com<mailto:stdake at cisco.com>> wrote:


From: Madhuri Rai <madhuri.rai07 at gmail.com<mailto:madhuri.rai07 at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, March 23, 2015 at 1:53 AM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient

Hi All,

This is to have a discussion on the blueprint for implementing python-k8client for magnum.

    https://blueprints.launchpad.net/magnum/+spec/python-k8sclient

I have committed the code generated by swagger-codegen at https://review.openstack.org/#/c/166720/.
But I feel the quality of the code generated by swagger-codegen is not good.

Some of the points:
1) There is lot of code duplication. If we want to generate code for two or more versions, same code is duplicated for each API version.
2) There is no modularity. CLI code for all the APIs are written in same file.

So, I would like your opinion on this. How should we proceed further?

Madhuri,

First off, spectacular that you figured out how to do this!  Great great job!  I suspected the swagger code would be a bunch of garbage.  Just looking over the review, the output isn’t too terribly bad.  It has some serious pep8 problems.

Now that we have seen the swagger code generator works, we need to see if it produces useable output.  In other words, can the API be used by the magnum backend.  Google is “all-in” on swagger for their API model.  Realistically maintaining a python binding would be a huge job.  If we could just use swagger for the short term, even though its less then ideal, that would be my preference.  Even if its suboptimal.  We can put a readme in the TLD saying the code was generated by a a code generator and explain how to generate the API.

One last question.  I didn’t see immediately by looking at the api, but does it support TLS auth?  We will need that.

Super impressed!

Regards
-steve



Regards,
Madhuri Kumari

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150323/da9deaa8/attachment.html>