Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi All, As we are using fedora-21-atomic-2 image and that has Kubernetes v0.11.0, I tried to run v1beta3 APIs on it. Some of the APIs failed. The Kubernetes developer said v1beta3 wasn't fully supported until the 0.15.0 release. Hence this is causing some APIs to fail. Below are the failures: 1. service-create API fail(422 status) with v1beta3 request format. The request format has changed from v1beta1 to v1beta3. https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api.md#v1beta3-conversion-tips I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7157 2. pod-create API fail(500 status) with invalid request format. While doing negative testing, I found that pod-create API fails with 500 status. It should actually fail with 400 status. I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7087 3. pod-update API fail(404). While trying to update a pod*, *it failed with status 404 even if the pod exists. This is due to duplicate replacePod API in Kubernetes Client code. I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7100 4. All APIs fail with json manifest. All Kubernetes resources(pod, rc, service) now fails with json format manifest due to issue in swagger-codegen generated Kubernetes Client code. It doesn't support unicode string. After all this issues, can we really switch to Kubernetes Client in this release or should we wait for the Fedora image with Kubernetes 0.15.0 release that has full support of v1beta3? Please provide your suggestions on this so that I can proceed further. Thanks Regards Madhuri Kumari On Tue, Mar 24, 2015 at 10:37 AM, Madhuri Rai madhuri.ra...@gmail.com wrote: Hi Hongbin, On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu hongbin...@gmail.com wrote: 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? I agree that's a concern. I will try to fix the pep8 error upstream to look how it take to push a change upstream. Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi Madhuri, 1) I think we'd better not jump to v1beta3 API if our image not updated. In release, we need to provide person with easy to use and function works well. As you mentioned, the v1beta3 not work with our image with many issues. 2) If we could update our image, which integrate the latests k8s 0.15.0 release, I support to use v1beta3. @sdake may knows how to update image, maybe others also, I not know much about it how to update such image. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） Follow your heart. You are miracle! From: Madhuri Rai madhuri.ra...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 04/22/2015 05:36 PM Subject:Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient Hi All, As we are using fedora-21-atomic-2 image and that has Kubernetes v0.11.0, I tried to run v1beta3 APIs on it. Some of the APIs failed. The Kubernetes developer said v1beta3 wasn't fully supported until the 0.15.0 release. Hence this is causing some APIs to fail. Below are the failures: 1. service-create API fail(422 status) with v1beta3 request format. The request format has changed from v1beta1 to v1beta3. https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api.md#v1beta3-conversion-tips I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7157 2. pod-create API fail(500 status) with invalid request format. While doing negative testing, I found that pod-create API fails with 500 status. It should actually fail with 400 status. I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7087 3. pod-update API fail(404). While trying to update a pod, it failed with status 404 even if the pod exists. This is due to duplicate replacePod API in Kubernetes Client code. I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7100 4. All APIs fail with json manifest. All Kubernetes resources(pod, rc, service) now fails with json format manifest due to issue in swagger-codegen generated Kubernetes Client code. It doesn't support unicode string. After all this issues, can we really switch to Kubernetes Client in this release or should we wait for the Fedora image with Kubernetes 0.15.0 release that has full support of v1beta3? Please provide your suggestions on this so that I can proceed further. Thanks Regards Madhuri Kumari On Tue, Mar 24, 2015 at 10:37 AM, Madhuri Rai madhuri.ra...@gmail.com wrote: Hi Hongbin, On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu hongbin...@gmail.com wrote: 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? I agree that's a concern. I will try to fix the pep8 error upstream to look how it take to push a change upstream. Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@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
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
From: Madhuri Rai madhuri.ra...@gmail.commailto:madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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? Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@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-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
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
From: Hongbin Lu hongbin...@gmail.commailto:hongbin...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 8:37 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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) std...@cisco.commailto:std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.commailto:madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribehttp://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
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
On Mar 23, 2015, at 9:05 AM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: From: Hongbin Lu hongbin...@gmail.commailto:hongbin...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 8:37 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 ;) +1 The big issue with submitting changes to swagger is swagger is written in erlang – groan. I doubt changes we would need upstream would be so dramatic that we could not make them in erlang. It’s probably tweaks here and there, and not rewrite level work. Adrian Regards, -steve Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.commailto:madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribehttp://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.orgmailto: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
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi Steven, On Mon, Mar 23, 2015 at 11:11 PM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@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. I have started working on it and will surely look whether some improvement can be done or not. And also will try to use it magnum. One last question. I didn’t see immediately by looking at the api, but does it support TLS auth? We will need that. I am not sure about it. I will check and let you know. Super impressed! Regards -steve Regards, Madhuri Kumari __ 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 Regards, Madhuri Kumari __ 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
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi Hongbin, On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu hongbin...@gmail.com wrote: 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? I agree that's a concern. I will try to fix the pep8 error upstream to look how it take to push a change upstream. Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@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-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 Regards, Madhuri Kumari __ 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
