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 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] On Behalf Of Addepalli, Srinivasa R
Sent: Wednesday, June 13, 2018 3:29 AM
To: MORALES RUVALCABA, VICTOR; 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] On Behalf Of Morales, Victor
Sent: Tuesday, June 12, 2018 8:47 AM
To: 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
