Clarification around multiple files in the cni conf folder

[ibuildthecloud]

I'm looking at three reference points to try to determine the correct behavior of multiple files in /etc/cni/net.d. According to the spec the runtime should choose and execute multiple plugins but how it chooses them is a bit fuzzy.

1. ./scripts/* just runs all plugins found in net.d
2. cnitool only runs a single plugin that matches name
3. k8s just picks the first valid JSON in net.d

What is the correct behavior?

[rosenhouse]

I may be mistaken, but I believe that behavior is intentionally outside the scope of the CNI spec. Runtimes are free to do whatever they like.

[dcbw]

k8s behavior is somewhat under-intentional right now (eg, we didn't have clarity around how multiple networks work and how they would be selected in the k8s world) but there are active, slow discussions happening in the Net SIG around that. More discussion is needed here all around, not just in k8s I think.

[MikeSpreitzer]

Heck, I think we need more clarity about those files, period. The spec does not actually define files. It defines what a plugin receives on stdin, as a "network configuration". And yet, we are slouching towards making files on disk do double-duty: (1) provide most or all of a network config, and (2) tell a runtime about a plugin (e.g.., note the way a file conveys "capabilities" about a plugin to a container runtime).

[squeed]

Right now this is not defined in the spec, but it is in libcni. However, there are no runtimes yet using the "standard" libcni library resolution logic. (I'm working on changing that in rkt, FWIW).

Rkt's network resolution logic is a bit more documented. Perhaps it's time to get off our lazy butts and properly write some godoc for libcni.

[MikeSpreitzer]

@ibuildthecloud : in what sense was this completed?