Weekly meeting (01/22/2019)

Patch is created with code changes

Working on overriding the values in Helm charts

Unit testing are pending

Yet to be done

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

Exposed API to upload cloud specific artifacts in tgz form.

Code is merged

Unit testing is also done

Functional test is to be done

To Eric question:

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

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

Developing code.

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.

Coding done

Unit testing is done.

Functional testing is yet to be done

Helm charts are created

Tested deployment using EdgeXFoundry Helm charts

CSAR yet to be done

Libo in contact with PTL based on the design document.

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

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)

Victor also to check MC code to see who makes calls to A&AI to get cloud reachability information

To be done

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

support full functional service design on k8s based VNF: In SDC service design, designer creates a service composing of 2 k8s based VNFs and a generic network to connecting them. How to support this scenario?

Q1: SDC can NOT do this unless it understands the helm chart to extract those 'port' information which could be used to connect to the NS level network. Need to on-board a dummy heat VNF and do service design to see what SDC's distributed internal csar would look like.

Q2: How SO understand the NS level network from SDC's distributed internal csar(NOT the onboarding zip) to create 'network' in k8s? Need to check how existing SO deal with heat VNFs about the same situation.

Eric ?

Liang ?