cloud-init's networking hotpug functionality waits and retries unnecessarily if one reloads a NIC's driver.
If one executes modprobe --remove ena then the kernel does trigger an udev remove event on the NICs using that driver and cloud-init's hotplug reacts to it:
2024-09-16 11:44:53,003 - hotplug_hook.py[DEBUG]: hotplug-hook called with the following arguments: {hotplug_action: handle, subsystem: net, udevaction: remove, devpath: /devices/pci0000:00/0000:00:05.0/net/ens5}
This does instruct cloud-init to re-fetch the datasource information and re-configure the network. But, as per AWS and the IMDS those NICs are still present in the IMDS and thus, cloud-init does not remove them. Then, the hotplug functionality realises that (that the udev-removed NIC is still present in the network configuration) and keeps waiting and retrying for a while.
Bug report
cloud-init's networking hotpug functionality waits and retries unnecessarily if one reloads a NIC's driver.
If one executes
modprobe --remove ena
then the kernel does trigger an udev remove event on the NICs using that driver and cloud-init's hotplug reacts to it:This does instruct cloud-init to re-fetch the datasource information and re-configure the network. But, as per AWS and the IMDS those NICs are still present in the IMDS and thus, cloud-init does not remove them. Then, the hotplug functionality realises that (that the udev-removed NIC is still present in the network configuration) and keeps waiting and retrying for a while.
Additional info
SF: #395673
Steps to reproduce the problem
modprobe --remove ena && modprobe ena
Alternatively, apply this patch and execute:
Environment details
cloud-init logs
cloud-init(2).tar.gz