Hi Arash,
Your assumption is correct, multicloud plugins have the choice
to use Go or any other language since they are located in separate repo and
delivered as separate micro-services.
Given the facts that k8s plugin is a brand new multicloud
component and the MultiCloud’s committers/contributors are more
involved/concerned on the collaboration/contribution here, this discussion
thread is to brainstorm on the opinions with regarding to pros/cons of each
choice.
Ideally we can achieve consensus after fully discussion/debating. But if not, I
expect there is some guideline/approach to settle down the disruption so that
everyone could follow.
Thanks.
Best Regards,
Bin Yang, Solution Readiness Team, Wind River
Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
From: Arash Hekmat [mailto:arash.hek...@amdocs.com]
Sent: Wednesday, June 13, 2018 10:04 PM
To: HU, BIN; Yang, Bin; ADDEPALLI, SRINIVASA; MORALES RUVALCABA, VICTOR;
onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua; Huang, Yun
Subject: RE: [onap-discuss] Building blocks for multicloud k8s plugin, RE:
[coe] Team meeting Agenda
Hi MultiCloud Team,
My 2 cents here.
I believe if below conditions are true, the K8S plugin can be implemented in Go
or any other language. But if they are not true, it should probably match
MultiCould’s core and use Python, for all the maintainability and integration
concerns already raised.
The K8S plugin can use Go or any other language if:
1. It has its own separate git repo
2. It runs in its own separate docker container
3. It does not directly call or share MultiCould’s Python framework
Arash
From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of HU, BIN
Sent: Wednesday, June 13, 2018 2:02 AM
To: Yang, Bin <bin.y...@windriver.com>; ADDEPALLI, SRINIVASA
<srinivasa.r.addepa...@intel.com>; MORALES RUVALCABA, VICTOR
<victor.mora...@intel.com>; onap-discuss@lists.onap.org
Cc: Zhang, Xiaohua <xiaohua.zh...@windriver.com>; Huang, Yun
<yun.hu...@windriver.com>
Subject: Re: [onap-discuss] 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<mailto:srinivasa.r.addepa...@intel.com>>;
MORALES RUVALCABA, VICTOR
<victor.mora...@intel.com<mailto:victor.mora...@intel.com>>;
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; HU, BIN
<bh5...@att.com<mailto:bh5...@att.com>>
Cc: Huang, Yun <yun.hu...@windriver.com<mailto:yun.hu...@windriver.com>>;
HUANG, HAIBIN <haibin.hu...@intel.com<mailto:haibin.hu...@intel.com>>; Zhang,
Xiaohua <xiaohua.zh...@windriver.com<mailto: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
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
