cni
cni copied to clipboard
CNI_ARGS with plugin chaining
Currently pkg/types/args.go
expects each plugin consumes all CNI_ARGS given from user.
For example, when host-local is invoked with CNI_ARGS="IP=1.1.1.1;TESTARG=TESTVAL", host-local is failed because 'TESTARG=TESTVAL' is not used in host-local plugin.
In plugin chaining case, we could not expect it because some CNI_ARGS will be consumed other CNI plugins.
For example, in the following netconf, user may add CNI_ARGS="IP=1.1.1.1;TESTARG=TESTVAL": IP for host-local and TESTARG for METAPLUGIN, however current pkg/types/args.go
raise error at host-local because TESTARG is unknown to host-local.
{
"cniVersion": "0.3.1",
"name": "test",
"plugins": [
{
"type": "ptp",
"ipam": {
"type": "host-local",
"subnet": "10.1.1.0/24"
},
"dns": {
"nameservers": [
"10.64.255.25",
"8.8.8.8"
]
}
},
{
"type": "METAPLUGIN uses CNI_ARGS, TESTARG=TESTVAL",
// OTHER CONFIG(snip)...
}
]
}
With IgnoreUnknown=true
, we could skip the check, however I suppose we could remove this check or we should write 'IgnoreUnknown' in somewhere.
Good spot. I don't see any alternative to effectively defaulting IgnoreUnknown
to true
in a chained configuration.
@bboreham I agree, but for now I don't come up with how to disable the check only in a chained case, because when the LoadArgs()
in pkg/types/args.go
is called, no way to identify whether chained case or not...
In addition, not only in chained case, similar case could be happen when both IPAM and interface CNI (e.g. bridge) consume CNI_ARGS in the future, hence I suppose we could just remove the check.
Any thoughts?
We are seeing this exact situation when passing an IP=xxx
arg intended for IPAM, now that in containernetworking/plugins v1.0.1 the bridge
plugin consumes an arg (mac from https://github.com/containernetworking/plugins/pull/636).
(Ref https://github.com/sylabs/singularity/pull/337)
(We have started appending IgnoreUnknown=1)