CNI_ARGS with plugin chaining

[s1061123]

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.

[bboreham]

Good spot. I don't see any alternative to effectively defaulting IgnoreUnknown to true in a chained configuration.

[s1061123]

@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?

[dtrudg]

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 containernetworking/plugins#636).

(Ref sylabs/singularity#337)

(We have started appending IgnoreUnknown=1)