interface name is now mandatory for dynamic networks attachements

[kmabda]

In multus a network interface name in a pod is optional, if the user didn't provide an interface name in the pod's network annotation the latter will be given a net1, net2, etc. as interface name.

To be able to hot-plug/unplug an network interface in a running pod the user must provide an interface name (as it should be) for the network-selection-elements

If a pod get configured with a multus network annotation without providing an interface name, it's not possible to unplug an interface from a running pod unless one add an interface name to the desired network-selection-elements (which would fails since the interface is already plugged) than unplug it (not a good user experience)

see also #48

To Reproduce
Steps to reproduce the behavior:

1. use the example in the README.md https://github.com/maiqueb/multus-dynamic-networks-controller#adding--removing-network-interfaces
2. remove the only network annotation element present
3. the request would be rejected since the selected network element don't have an interface name.

Environment:

• multus-dynamic-networks-controller version: N/A
• Kubernetes version (use kubectl version): N/A
• Network-attachment-definition: N/A
• OS (e.g. from /etc/os-release): N/A
• Controller configuration (criSocketPath / multusSocketPath): N/A
• Kernel (e.g. uname -a): N/A
• Others: N/A

Additional info / context
Not sure how this should be resolved since we can't change current multus behaviour regarding having an interface name optional, but though this should be tracked some how!

[maiqueb]

How about we adapt the code to reject handling the update of an existing attachment ? I.e. allow the user to patch the existing annotation's on a pod adding the interface name to the network selection elements, without triggering add / remove of the interface ?

This was my original intention, and honestly, I thought the current code would do that.

... I just checked and can confirm it doesn't.
@kmabda

[kmabda]

@maiqueb yeah I think that's would be one approach of handling it right now with the current deficient edge level triggered updates strategy.

This would apply I assume as well to other NetworkSelectionElement elements which are not relevant to hot-plug/unplug an interface into a running pod e.g. IPRequest, MacRequest etc.

Ideally would be nice to give feedback why things didn't works as expected when someone let say hot-plug/hot-unplug a network selection element without providing an interface name when doing kubectl describe pod in the events log or when modifying attributes not relevant to the add/del operation (didn't check if this is already the case or not though)

[maiqueb]

Yeah - my intention is to prevent the update of any existing attachment. That would be outside the scope of this project.

Hmm, we could throw an event / log.

Opened #66 to track this.