interface name is now mandatory for dynamic networks attachements
kmabda opened this issue · 3 comments
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:
- use the example in the README.md https://github.com/maiqueb/multus-dynamic-networks-controller#adding--removing-network-interfaces
- remove the only network annotation element present
- 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!
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
@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)