> As far as a fix goes, I'm leaning towards not including the udev rule during
> install, then installing it during our normal boot process if we detect that
> hotplug has been enabled.
I think this makes a lot of sense. IIRC, we don't attempt to handle hotplug
events on firstboot, so it's reasonable to write the new udev rule if enabled
and reload rules (udevadm control --reload)
Another optimization for the rule would be to have it not invoke cloud-init
directly to determine if hotplug is enabled (python3 is a heavy exec).
When cloud-init checks for hotplug config, it can serialize into
/run/cloud-init the current status of hotplug) and I think like
cloud-init.disabled, we could also have a marker file that the hook can check
in the shell script to avoid any exec of python at all).
> As far as a fix goes, I'm leaning towards not including the udev rule during
> install, then installing it during our normal boot process if we detect that
> hotplug has been enabled.
I think this makes a lot of sense. IIRC, we don't attempt to handle hotplug
events on firstboot, so it's reasonable to write the new udev rule if enabled
and reload rules (udevadm control --reload)
Another optimization for the rule would be to have it not invoke cloud-init
directly to determine if hotplug is enabled (python3 is a heavy exec).
When cloud-init checks for hotplug config, it can serialize into disabled, we could also have a marker file that the hook can check
/run/cloud-init the current status of hotplug) and I think like
cloud-init.
in the shell script to avoid any exec of python at all).