Weekly meeting (01/29/2019)

Patch is created with code changes

Updating with override is values done.

Unit testing are pending (Will be done after return from vacation)

Yet to be done

Based on VNF UUID passed by SO, it shall lookup artifacts and then act on it.

TBD: VNF UUID that is passed today to MC is not the VSP ID. I guess we need to raise JIRA for SO to pass additional IDs that help in looking up VSP artifacts in MC (Changes to API) - Create JIRA (AR: Srini)

Done

To Eric question:

• All artifacts are stored in MongoDB. Indexed by VSP IDs.

Defined the metadata file (Please create a file in the document directory and paste the link in the wiki page)

Code done

Manual functional testing is done

Tested with Helm charts.

Unit testing yet to be done (Kiran to do once return from vacation)

Config-map is not yet done (configure file override from configuration profile) - Only override values are taken care (Kiran to do once return from vacation)

MULTICLOUD-454  - Provider network support when OVN is used

Create multiple JIRA stories

1. To update KRD to use non-NAT libvirt networks.
2. Explore creation of multiple providers networks and place PODs in multiple provider networks as well as virtual networks.
3. Discovery of provider networks
4. Create specification on how deployments describe provider networks
5. K8S plugin enhancements & route operator in K8S regions - to Update routes in minion nodes that are hosting provider network gateways.
   
   

Status:

• Exploring provider network usage in OVN.
• She was exploring vagrant networks with no NAT (Pretty close to make this work)

Coding done

Unit testing is done.

Functional testing is yet to be done

Yet to be started

1. Create helm charts and test directly using K8S plugin (Akhila and Victor)
2. CSAR creation (once SDC client is done and SO changes are done)

Helm charts are created

Tested deployment using EdgeXFoundry Helm charts

CSAR yet to be done

the design spec has been reviewed with MultiCloud PTL

Libo has uploaded the design document here (K8S based Cloud-region support - Documents)

details discussion about currently k8s API and flow.

the SDC client in Multicloud is supposed to :

1. acts as a sidecar, running with the plugin like k8s which are interested in the same pod
2. retrieve the artifacts from SDC's distribution
3. store it on shared volume based on specified rule (perhaps using UUID from artifact metadata)
4. inform the plugins 's callback API.

the callback API is supposed to be ONLY one, and be added into the configuration file for the each client. the API of k8s could access the artifacts from shared volume and store it into mongoDB as own choice.

To provide an example configuration file.

Getting cloud-region reachability from Multi-Cloud.

Victor to check with A&AI PTL on whether there are any size limitations (Kubeconfig can go up to 10K in size)

Got clarity on what to be done in Plugin

To be done

Schema change

ESR Change

need check with SDC PTL about what's additional step need to do besides chnage

catalog-be/sdc-backend-init/chef-repo/cookbooks/sdc-catalog-be-setup/templates/default/consumers.py.erb file

Create individual JIRA stories

Eric to look at the A&AI updates being done by HeatBridge and then create JIRA story as similar stuff needs to be done by K8S plugin