chaining user story

[philips]

Sorry for not paying attention here for a long while. I saw that the chaining stuff was merged and I am wrapping my head around the design.

But, we need to provide a user story on how a user becomes unaware that chaining is happening to accomplish things like port forwarding. My understanding with the design of chaining is that the user won't need to be aware that this plugin is being injected by their platform. The way I see it working:

I will walk through a flannel example with Kubernetes:

1. User puts flannel CNI plugin in /opt/cni/bin/flannel and a config into /etc/cni/net.d/my-network and tells their system to use "my-network" configuration.

2. The Kubelet then creates a chained plugin configuration in-memory something like:

{
  "cniVersion": "0.2.0",
  "name": "my-network",
  "plugins": [
    {
      "name": "cbr0",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true
      } 
    },
    {
      "type": "kubernetes-port-forward",
       "port_mappings" : [
         { "host_port" : 8080, "container_port" : 80 },
         { "host_port" : 8081, "container_port" : 443 }
       ]
    }
}

3. The Kubelet execs the /opt/cni/bin/cni-plugin with this configuration sent to stdin and CNI_PATH=/usr/share/kubelet/cni/bin:/opt/cni/bin

[philips]

cc @thockin @squeed @dcbw

[thockin]

What you describe sounds right. The issue of how the user tells kubelet which plugin is handling portmapping is still open, but otherwise, yeah. Someone somewhere crafts a config which is a set of plugins.

[philips]

@squeed @tomdee With https://github.com/containernetworking/cni/pull/369 should we revert chaining?

[squeed]

No, #369 still relies heavily on chaining.

[philips]

@squeed can someone write a user story of how this whole thing works end to end then?