-
Type:
Task
-
Status: Resolved (View Workflow)
-
Priority:
Medium
-
Resolution: Won't Do
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Kubernetes, VTN
-
Labels:None
-
Story Points:5
-
Sprint:QP Sprint #6
-
Epic Link:
It looks like we need a strategy and reasonable design for how VTN will interact with K8S.
Some thoughts from Scott:
*****
The three most important VTN design documents I think are https://wiki.opencord.org/display/CORD/Virtual+Network+Overlay, https://wiki.opencord.org/display/CORD/VTN+Design+Note and https://wiki.opencord.org/display/CORD/VTN+Data+Models+and+REST+API. The first one is an overview. The second one talks about what VTN programs the flow rules, and the second one talks about the API used to interact with VTN. The VTN synchronizer currently handles all the API interaction, but probably does so using OpenStack-like mindset (Instances have IP addresses on Networks, and VTN's job is to program flow rules for those Instances to talk to one another).
I think the first step is probably to read the overview and see how much of this is relevant anymore. Originally it was envisioned there was going to be this VNF -> VNF -> VNF pipeline, and each VNF would have a load balancer that sent packets to the right Instance (sounds a lot like k8s to me). That never really came to pass, we typically had one dataplane VNF (the vsg) and there were no load balancers.
*****
I will begin looking at VTN so we can evolve the design in an iterative way
