gdisk:
Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8C5E98A4-0D1E-40AE-8F43-80544A2C204B
We could leverage that for software that needs to create its own partitions after deployment in MAAS for example. In this case there will be no need to create a new partition table post-deployment but there will be no partitions or file systems on a block device which will be ready for any use.
Example: Ceph needs to use block devices to create partitions but "zapping" of a partition table is configurable. If a partition table is pre-zapped during the deployment and a new clean one is created ceph-disk can just create partitions on an existing partition table.
Serial numbers are not super reliable as they depend on a block driver while in this case we rely on a superblock written at the deployment time. Even if we have an odd device that doesn't have reliable means of identification we can rely on a persistent UUID we ourselves put onto that device.
MAAS needs to grow an ability to configure empty block devices which will get a clean partition table at will too.
I think it's worthwhile to create a udev rule for ubuntu server in general: /dev/disk/by-gpt-uuid/<uuid>
Block devices can be identified by a GPT placed on them.
Each partition table contains a UUID which uniquely identifies a device.
sudo blkid -o udev -p /dev/nvme0n1 TABLE_UUID= 8c5e98a4- 0d1e-40ae- 8f43-80544a2c20 4b TABLE_TYPE= gpt
ID_PART_
ID_PART_
gdisk: 0D1E-40AE- 8F43-80544A2C20 4B
Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8C5E98A4-
We could leverage that for software that needs to create its own partitions after deployment in MAAS for example. In this case there will be no need to create a new partition table post-deployment but there will be no partitions or file systems on a block device which will be ready for any use.
Example: Ceph needs to use block devices to create partitions but "zapping" of a partition table is configurable. If a partition table is pre-zapped during the deployment and a new clean one is created ceph-disk can just create partitions on an existing partition table.
Serial numbers are not super reliable as they depend on a block driver while in this case we rely on a superblock written at the deployment time. Even if we have an odd device that doesn't have reliable means of identification we can rely on a persistent UUID we ourselves put onto that device.
MAAS needs to grow an ability to configure empty block devices which will get a clean partition table at will too.
I think it's worthwhile to create a udev rule for ubuntu server in general: /dev/disk/ by-gpt- uuid/<uuid>