Move 'VF/MAC/VLAN' from NetConf to NetArgs by following the CNI spec

[hustcat]

Move 'VF/MAC/VLAN' from NetConf to NetArgs by following the CNI spec.

[rkamudhan]

Hi Yin,

Is it something like below?

{
  "name": "sriov-net",
  "type": "sriov",
  "master": "eth1",
  "args": {
    "vf": 1,
    "mac": "66:d8:02:77:aa:aa"
  },
  "ipam": {
    "type": "host-local",
    // ipam specific
    "subnet": "10.1.0.0/16",
    "gateway": "10.1.0.1"
  },
  "dns": {
    "nameservers": [ "10.1.0.1" ]
  }
}

[rkamudhan]

Is there any reason to use fixipam?

[hustcat]

No, any IPAM plugin is OK:)

[rkamudhan]

Can we add a example of Args here. So that user can understand it ?

[rkamudhan]

I will test it and let you know asap.

[hustcat]

@rkamudhan By CNI spec:
Maybe we use master as args field in network configuration, and use VF，MAC etc. as args field in Parameters that for simple configuration on a per-container basis.

However, this PR don't include using master as args field in network configuration. I will add it later:)

[hustcat]

@rkamudhan I am waiting your testing reply :)

[rkamudhan]

@hustcat
I think, it is better "master" field not added in the args field, I see args as the parameter, which should be optional, without args parameter also SRIOV plugins should work. But without master and ipam, Currently, SRIOV plugin can't work. Please join in our slack https://intel-corp.herokuapp.com/, I like to discuss with you about our forked version of sriov https://github.com/Intel-Corp/sriov-cni, we added so many features to your SRIOV plugin.

[hustcat]

@rkamudhan The features you added are so amazing, I'd like to merged it if you like. CNI spec allow plugin added its own optional fields for network configuration, so add master field is OK.

But I still wonder how these optional fields can be integrated with Kubernetes. see 1, 2.

Mapping Network Objects to CNI
When using CNI networking, the kubernetes CNI plugin would search for a file in /etc/cni/net.d with a JSON “name” key that matched the Network object name. It would then execute this CNI config only. When the “ordered chaining” (#346) PR gets merged, this would also search for a “.conflist” file that contains a sequence of plugins to run.

IPAM would be handled by the CNI config JSON just like it currently is.

In addition, I'd like to merge this PR if you don't have other opinions.

[rkamudhan]

@hustcat , I think CNI Args will be a part of pod spec in kubernetes, which are optional. The .conflist file work similar to the Multus plugin

[hustcat]

@rkamudhan Thanks, I‘ll merged this PR now. After this, let's merge your DPDK and other features:)