use dummy UUIDs for NM; since those would change every boot
Bug #1727031 reported by
Mathieu Trudel-Lapierre
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
netplan.io (Ubuntu) |
Triaged
|
Low
|
Unassigned | ||
nplan (Ubuntu) |
Invalid
|
Low
|
Unassigned |
Bug Description
Use dummy UUIDs:
00000000-
^ would do just fine; since that's unlikely to end in a collision and a generated UUID would never be the same across reboot.
To post a comment you must log in.
The underlying justification here is that currently, we are wasting (possibly scarce) entropy at each boot to generate a UUID whose global uniqueness provides no particular value to us because it doesn't persist across reboots (therefore you can't usefully refer to it from elsewhere anyway).
We have two ways to generate a UUID with libuuid: one is to use the system mac address plus the current time, the other is to use a true RNG. The first method presents a chicken-and-egg problem for netplan, because the libuuid implementation only looks at mac addresses of "up" interfaces, which we don't have at the time netplan runs at boot. So we fall back to an RNG, which means each time netplan generates NM config, it gets a different identifier for the connection config.
Using serial ids (00000000- 0000-0000- 0000-0000000000 01, 00000000- 0000-0000- 0000-0000000000 02, ...) may not be optimal because things that *do* generate references to these connections on the system will potentially be referring to different connections with the same ID across reboot.
Another option is for netplan to do its own implementation of guaranteed- not-to- collide and *idempotent* UUIDs, so that the same config repeatably produces the same identifier. Suggestion for input to the algorithm:
- machine UUID (if available early enough on first boot), or mac address of corresponding network device
- mtime of the netplan config file
- name of the device (==netplan yaml key)