I didn't think there was a MAAS released that would provide only path: to disks. This is somewhat surprising since path is just not stable.
While we can warn when we attempt to create a dname for a disk without serial/wwn and move on; I do think MAAS should require serial/wwn. No one looks at the curtin log file on successful deploys; so this leaves the node open to unreliable dname if someone modifies the partition table (which is what this change was to fix) or plugs in a USB drive. Should we inject 'unstable' in to the dname value?
/dev/disk/by-dname/UNSTABLE-sda ../../sda
In terms of rule preference; we have some conflicting values. On some scsi disks, we get:
So, I'd like to see if we can build a reasonable order of preference. My initial thought based on my experience would be to prefer values in this order:
I didn't think there was a MAAS released that would provide only path: to disks. This is somewhat surprising since path is just not stable.
While we can warn when we attempt to create a dname for a disk without serial/wwn and move on; I do think MAAS should require serial/wwn. No one looks at the curtin log file on successful deploys; so this leaves the node open to unreliable dname if someone modifies the partition table (which is what this change was to fix) or plugs in a USB drive. Should we inject 'unstable' in to the dname value?
/dev/disk/ by-dname/ UNSTABLE- sda ../../sda
In terms of rule preference; we have some conflicting values. On some scsi disks, we get:
ID_SERIAL WITH_EXTENSION
ID_SERIAL_SHORT
ID_WWN
ID_WWN_
So, I'd like to see if we can build a reasonable order of preference. My initial thought based on my experience would be to prefer values in this order:
ID_WWN_ WITH_EXTENSION
ID_WWN
ID_SERIAL
ID_SERIAL_SHORT
And lastly, curtin currently will embed as many of these values as are found.
DEVTYPE=={disk}, ENV{ID_ WWN_WITH_ EXTENSION} =="val" , ENV{ID_WWN}=="val"
I think by combining these values in the rule; we'll ensure we don't misidentify a disk.