Rkt: networking/kvm: should not continue to duplicate CNI code

[steveeJ]

The stage1-kvm flavor has been copying large snippets of code from CNI to mimic the behavior of the nspawn based stage1-coreos flavor, and I think it is time to move away from this pattern. This issue will be used to track progress as I think we need more than one PR for this.

[jellonek]

First part will be adding hypervisor specific code to CNI (i'll start to do this today).
Second - remove this code from rkt and start using cni in new way.
Third - a bit external - change way how k8s uses rkt in this area.

[lukasredynk]

I looked into this and the main problem is that CNI creates veth devices and unfortunately kvm cannot use them. I could see two solutions here:
1) If [1] would be merged then in rkt we could add code path for kvm flavor adding macvtap link to veth pair and passing it to kvm.
2) Add optional arg to the CNI (like CNI_VIRT) and if it'll be set then e.g. bridge plugin would setup macvtap/tap instead of veth device, IPAM would only reserve address without setting up interaface and top-most plugin with return the usual output, adding tap index via optional field in types.IPConfig.

First solution requires [1], which changes interface a lot. On the other hand second solution would introduce minor changes to existing interface (if CNI_VIRT would not be set there would be no changes in behavior and output) and would not break existing implementations.

Both solutions _should_ allow to remove CNI code from networking/kvm.go

Does it sound reasonable? Or I'm missing here something?

@steveeJ @jellonek @jjlakis @pskrzyns

[1] https://github.com/containernetworking/cni/pull/145
[2] https://lists.nongnu.org/archive/html/qemu-discuss/2015-10/msg00002.html

[jellonek]

@lukasredynk second solution is what I had in mind and what I wanted to implement (but personal things putted me off for a quite long time).

[lukasredynk]

I've got local version of code which uses both PRs [1] [2] with default-restricted netwrok (ptp). I think that porting other plugins after the path would be set will be relatively easy.

[1] Related WIP PR in cni repo: https://github.com/containernetworking/cni/pull/271
[2] Related PR in netlink repo: https://github.com/vishvananda/netlink/pull/154