Hi Bin,

We will leverage the work done by SMS to talk to AAF/ISTIO, logging etc…
CI/CD process was already proven by other projects such as SMS & Distributed KV 
Store and same process can be leveraged.
In regards to skillset & maturity of go-lang & Python vs go : Let us not 
discuss (if you don’t mind)  as this can become a big rathole ☺.


From: bin.y...@windriver.com [mailto:bin.y...@windriver.com]
Sent: Tuesday, June 12, 2018 8:27 PM
To: Addepalli, Srinivasa R <srinivasa.r.addepa...@intel.com>; Morales, Victor 
<victor.mora...@intel.com>; onap-discuss@lists.onap.org; HU, BIN 
(bh5...@att.com) <bh5...@att.com>
Cc: Huang, Yun (Wind River) <yun.hu...@windriver.com>; Huang, Haibin 
<haibin.hu...@intel.com>; Zhang, Xiaohua (Wind River) 
Subject: Building blocks for multicloud k8s plugin, RE: [coe] Team meeting 

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 

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

[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yang, Bin
Sent: Wednesday, June 13, 2018 9:21 AM
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 
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 ip>: <service 
               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.

Best Regards,
Bin Yang,    Solution Readiness Team,    Wind River
Direct +86,10,84777126    Mobile +86,13811391682    Fax +86,10,64398189
Skype: yangbincs993

[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Addepalli, Srinivasa R
Sent: Wednesday, June 13, 2018 3:29 AM
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.


[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 

Victor Morales
onap-discuss mailing list

Reply via email to