Open squeed opened 2 years ago
In CNI 2.0, we provide gRPC/Protobuf definition, so I think use protobuf any type is nature.
Example network configuration could be like:
{ "cniVersion": "1.0.0", "name": "dbnet", "plugins": [ { "type": "bridge", "bridge": "cni0", "extra": [ { // **plugin specific parameters for nerdctl** "@type": "type.googleapis.com/helloworld.NerdctlNetworkConfig", "NerdctlID": 112233, "NerdctlLabels": { "bob": "11" } }, { // **plugin specific parameters for bridge** "@type": "type.googleapis.com/k8s.cni.cncf.io/v1.0.0.BridgeNetworkConfig", "configKey": "configValue" } ], "ipam": { "type": "host-local", // ipam specific "subnet": "10.1.0.0/16", "gateway": "10.1.0.1", "routes": [ { "dst": "0.0.0.0/0" } ] }, "dns": { "nameservers": [ "10.1.0.1" ] } }, { "type": "tuning", "capabilities": { "mac": true }, "sysctl": { "net.core.somaxconn": "500" } }, { "type": "portmap", "capabilities": { "portMappings": true } } ] }
And protobuf any type can be converted to json.
I submitted a pr, https://github.com/containernetworking/cni/pull/874 .
Assuming we move forward with daemonization (#821), then we will have to write a protobuf schema for the CNI protocol. This tpresents a few awkward edges around network configuration.
The gist of the issue is this:
So, we need some way to ergonomically pass, to a plugin, a network configuration. This configuration is user-defined but plugin specific.
Options