This suggestion from Bin “Or expand the “esr-system-info-list” with a new property for kubeconfig information” seems to good and worth looking into it. It is good to introduce “reachability_opaque_data”. In K8S, it could be information required for K8S plugin to talk to K8S masters. Let us discuss this further.
On authentication: I would go with certificate based authentication (as this and token based authentication is preferred method by K8S deployers). On making unique metadata name: Please do let us know on your proposal. I could not quite understand it. https://github.com/kubernetes/client-go/tree/master/examples/create-update-delete-deployment If you look at main.go file there, deployment in K8S is done using “Name” of the deployment object (line 60). When they are deleting or updating, it uses this name. Since in our case, we are using same artifact multiple times (for multiple K8S VNF deployment), we need to ensure that this name is unique. Hence the UUID generation and concatenation proposal. Thanks Srini From: Morales, Victor Sent: Tuesday, June 12, 2018 4:02 PM To: HU, BIN <bh5...@att.com>; Addepalli, Srinivasa R <srinivasa.r.addepa...@intel.com>; onap-discuss@lists.onap.org Subject: Re: [coe] Team meeting Agenda Hey there, @Bin, I have a question about using the ESR VIM registration portal. According to the wiki using this method will trigger a discovery process. I’m wondering if we have to create an endpoint for this, maybe it’s something that we can include into the API definition and implement it later. @Srini regarding your questions, for this PoC we have only considered the scenario for consuming the ./kube/config[1] file. In the other hand, I noticed that’s possible to configure Kubernetes to use Basic Authentication method [2] which can do something similar than OpenStack. Lastly, regarding the concatenation I have the impression that what Kubernetes is doing internally is quite enough to guarantee its uniqueness, but we can include it as a functional test to cover that scenario. Regards, Victor Morales [1] https://github.com/electrocucaracha/krd/blob/master/installer#L97 [2] https://github.com/electrocucaracha/krd/blob/master/inventory/group_vars/k8s-cluster.yml#L69 From: "HU, BIN" <bh5...@att.com<mailto:bh5...@att.com>> Date: Tuesday, June 12, 2018 at 1:04 PM To: "Addepalli, Srinivasa R" <srinivasa.r.addepa...@intel.com<mailto:srinivasa.r.addepa...@intel.com>>, Victor Morales <victor.mora...@intel.com<mailto:victor.mora...@intel.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: RE: [coe] Team meeting Agenda Refer to the wiki page: https://wiki.onap.org/pages/viewpage.action?pageId=25431491 (How-To: Register a VIM/Cloud Instance to ONAP<https://wiki.onap.org/pages/viewpage.action?pageId=25431491>). In this guide, when registering a new VIM, we need to: - Create Complex object in A&AI - Register VIM/Cloud instance in A&AI - And some other steps When registering VIM/Cloud instance in A&AI, one can use curl command to create a cloud region object in A&AI. This Cloud Region Object contains a “esr-system-info-list” which includes “username” and “password” for keystone authentication. Because this schema is OpenStack-centric, we may have 2 options: - Reuse “password” property, and store kubeconfig information within this “password” property - Or expand the “esr-system-info-list” with a new property for kubeconfig information. Hope it helps Thanks Bin 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: Tuesday, June 12, 2018 12:29 PM To: Morales, Victor <victor.mora...@intel.com<mailto:victor.mora...@intel.com>>; 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