Hey there, First of all, every of these points are valid but also they have different perspectives. From our technical perspective as Srini mentioned during the MultiCloud meeting, we decided to choose Go as a programing language because it’s GoLang client is well-maintained by the Kubernetes community compared with others (something similar happens for the python client in OpenStack). I want to add that its go routines paradigm makes developers life easier to build multi-thread applications and its tools ecosystem is mature enough.
Regarding the points that you mention: · Implementation, integration and testing. There are other projects written in Go which have been integrated in ONAP. So, the effort to test them has been already done. Implement new mechanisms for the integration to other shared services is not a big deal given that all of them are offering a RESTful API which can be consumed by any language. · Collaboration and support. I want to mention that this is an open source project which means that its code is accessible to anyone. At same time, there is no guarantee that any contributor can be assigned indefinitely to this and/or any project but IMHO, the way to mitigate this is being open in sense of sharing code, documentation and processes and building a community. Lastly Go has been grown [1] in terms of adoption and popularity and its simplicity makes an easy learning curve. Regards, Victor Morales [1] https://www.tiobe.com/tiobe-index/go/ From: "HU, BIN" <bh5...@att.com> Date: Tuesday, June 12, 2018 at 11:02 PM To: "Yang, Bin (Wind River)" <bin.y...@windriver.com>, "Addepalli, Srinivasa R" <srinivasa.r.addepa...@intel.com>, Victor Morales <victor.mora...@intel.com>, "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org> Cc: "Huang, Yun (Wind River)" <yun.hu...@windriver.com>, "Huang, Haibin" <haibin.hu...@intel.com>, "Zhang, Xiaohua (Wind River)" <xiaohua.zh...@windriver.com> Subject: RE: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda If I understand correctly, there are 2 types of concerns regarding Go language (v.s. Python) here: - Implementation, integration and testing: e.g. CI/CD integration, reuse of shared services etc. - Long-term community support with the appropriate expertise in Go language. The 2nd one, i.e long-term community support is actually the biggest concern. For example, after K8S plugin is developed with Go language, but the original Go developer no longer works in ONAP, do we have a pool of Go developers in ONAP community that can comfortably take over the work of maintenance and further evolving K8S Plugin? Or will then-current developers have to re-develop K8S Plugin with Python or Java because most of ONAP developers are Python or Java developers? If there are very few Go developers in ONAP community, using Go language certainly brings huge risk of continuous support, maintenance and evolution in the future. My 2 cents Thanks Bin From: Yang, Bin [mailto:bin.y...@windriver.com] Sent: Tuesday, June 12, 2018 8:27 PM To: ADDEPALLI, SRINIVASA <srinivasa.r.addepa...@intel.com>; MORALES RUVALCABA, VICTOR <victor.mora...@intel.com>; onap-discuss@lists.onap.org; HU, BIN <bh5...@att.com> Cc: Huang, Yun <yun.hu...@windriver.com>; HUANG, HAIBIN <haibin.hu...@intel.com>; Zhang, Xiaohua <xiaohua.zh...@windriver.com> Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda Hi Victor, Srini and all, In addition to the agenda you listed, could you also add one more to touch the topic of building blocks (e.g. “language binding” with golang instead of python) for multicloud k8s plugin? I do understand that from the architecture perspective it is irrelevant w.r.t. how to implement the plugin service, hence up to developers/contributors’ choice. However, it is worth to think again for following reasons: 1, Leverage and Scale Aligning to existing practice of multicloud plugin implementation enables developers focus on the core value of the plugin, e.g. mediate ONAP orchestration to k8s cluster in case of multicloud k8s plugin. As part of ONAP projects it is required that the multicloud k8s plugin be integrated with CI/CD process and other shared services (e.g. AAF, centralized logging, etc.) Right now CI/CD support projects with python binding very well, and the logging AOP facility for Python is well supported, I don’t know if there is off-the-shelf utility for golang available yet. If multicloud k8s plugin align to the existing practice of openstack plugin and vio plugin, then you don’t have to invest further time/cost on those effort. 2, Facilitate more participation from current multicloud committers/contributors multicloud committers/contributors has been working on python already for a long time , and it is not surprising that many of them are willing to participate/contribute to this multicloud k8s plugin development. Assuming that Golang is not as widely adopted as Python so most of them is not that familiar with Golang compared to Python, it would lower the barrier for them to contribute if multicloud k8s plugin could adopt the same language and framework. 3, Decrease the maintenance cost from either community and the Service Providers who will productize ONAP By align to the same practice and share the same building blocks across multicloud plugins, one committer/contributor support/maintain one plugin could also be possible to support another one with low cost to learn/understand it. This will decrease the TCO which is always a pain of open source product compared to those commercialized close source product. 4, facilitate pairwise/integration testing for fast release cadence It might not concern those architect, but it is really a pain for developers who support the pairwise/integration testing. Fortunately, python make our life better since it is possible to fix the bug on runtime and test it immediately, which reduce the cycle of debugging. I can share you some feedback from several PTLs whom I had supported during Pairwise/integration test if you are interested to know. So it is my 2 cents, please let me know if you have other concerns/opinions and I am willing to learn them, thanks. Best Regards, Bin Yang, Solution Readiness Team, Wind River Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189 Skype: yangbincs993 From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yang, Bin Sent: Wednesday, June 13, 2018 9:21 AM To: ADDEPALLI, SRINIVASA; MORALES RUVALCABA, VICTOR; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [coe] Team meeting Agenda Hi Srini, and all, With regarding to the “each deployment instance needs to be uniquely identified”, what is the intention for this “uniquely identified”? I mean, who will care about/consume this unique ID? IMHO, from multicloud NBI consumers’ perspective, I don’t get the point to identify uniquely each deployment instance of multicloud plugin for following reasons: 1, every multicloud plugin could be deployed as a cluster/replicated set of “deployment instances” within a single ONAP instance, but they all should expose the NBI via the same endpoint. I assume every multicloud plugin are stateless service so that the consumer’s requests can be distributed via MSB or some other load balance mechanism . In that case multicloud consumers are not aware the “multiple deployment instances” of any multicloud plugin. 2, every multicloud plugin can also be deployed in the distributed way (e.g. deployed along with each edge ONAP instance). In this case the each multicloud deployment instance exposes unique NBI endpoint since the IP address of hosts (which are used to deploy the multicloud plugins) are different, so the consumers should be aware of which edge ONAP they are talking to. With either case the multicloud consumers are not necessarily identify uniquely the deployment instance. You may also wonder to know that how the consumers (SO, APPC,VFC) know what the multicloud plugin deployment instance’s NBI endpoint is in either cases above, here is my understanding : 1, The MultiCloud deployment instance’s NBI endpoint can be found from the cloud region in AAI (e.g. "identity-url": "http://<service<https://urldefense.proofpoint.com/v2/url?u=http-3A__-253Cservice&d=DwQGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=85aq405WfgHwU0C-y6F23V_WpTZA1WOtS4TZ3l-lzlg&s=_ZMhzvDm_TZMhLTiTfsda-hs9mMB236hnhiX3k0bGdc&e=> ip>: <service port>/api/multicloud-titanium_cloud/v0/CloudOwner2_RegionOne/identity/v2.0") 2, This identify-url are populated by multicloud plugin during the VIM/Cloud instance on boarding procedure. So it is possible that different cloud region are populated with different multicloud NBI endpoint. 3, Idealy, the VIM/Cloud instance on boarding procedure are triggered from and excuted in the context of respectively ONAP instance, so for those edge cloud orchestrated by edge ONAP will be on boarded via the edge ONAP ESR portal/API. In this case the multicloud plugin instance within the same ONAP instance will provision the cloud region with the consistent endpoints , I mean , with the same service ip :port . But the muticloud plugin instance from different ONAP instance will provision cloud region with different endpoint (I mean, different service ip: port) Does that make sense? Please let me know what you think of that. Thanks Best Regards, Bin Yang, Solution Readiness Team, Wind River Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189 Skype: yangbincs993 From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Addepalli, Srinivasa R Sent: Wednesday, June 13, 2018 3:29 AM To: MORALES RUVALCABA, VICTOR; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] [coe] Team meeting Agenda Hi Victor and Shashank, There were few questions from Multi-Cloud meeting yesterday (Shankar and others). It would be good if we could cover following also today - K8S plugin needs to have access to information that connect to K8S masters in the remote edge-clouds/sites. Normal practice for K8S client is to read kubeconfig file that has connectivity information for each cluster and certificate/private key to be used to communicate with remote site K8S master. In ONAP, we have ESR. Are we going to use ESR or K8S plugin provides its own way to upload kubeconfig information. If so, how does get stored in A&AI. Is there any schema change required? - K8S plugin at the run time will use same deployment template files multiple times. But, each deployment instance needs to be uniquely identified. Normally, ObjectMeta.Name is used to uniquely identify each deployment. I guess it means that K8S plugin needs to generate this name dynamically to make it unique. One way to do this is to create UUID, concatenate with Name field of deployment template (artifact) and store the UUID in the A&AI on per VNF basis. Does this require any A&AI schema changes? When Delete/Update/Query VNF is called at later time, it is expected that concatenated name is passed by SO (test SO in this case). Let us discuss this too today. Thanks Srini From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Morales, Victor Sent: Tuesday, June 12, 2018 8:47 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] [coe] Team meeting Agenda Hey there, These are the topics that I’d like to talk about today • Project status • API Definition Discussion • Opens But I want to check first if someone has an additional topic that needs to discussed. Regards, Victor Morales
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
