udev needs to be triggered if rules are written to a new file
Bug #1817368 reported by
Robert Schweikert
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Undecided
|
Robert Schweikert |
Bug Description
On a VM with many interfaces it is possible that udev is slow. This may lead to the situation that 70-persistent-
The user can already specify an optional rules file with the "netrules_path". However this will not have any effect when the file gets written as udev is not re-triggered. When the user configures a custom file (which logically should be something like 71-persistent-
Changed in cloud-init: | |
assignee: | nobody → Robert Schweikert (rjschwei) |
Changed in cloud-init: | |
status: | New → In Progress |
To post a comment you must log in.
I think we're in conflict with 75-persistent- net-generator. rules; as both cloud-init and that rule are attempting to map a MAC and interface name. This is going to be trouble, as you've seen.
Even if we sorted the race, if users may be confused as to the two files, or the interleaved values etc.
Does the image have systemd and persistent net naming enabled?
In cases like this, cloud-init has introduced logic to check if an in-image file is present and renames, or deletes it if it's taking an expected action (like generating persistent net rules for network config it has discovered).