I may have found a workaround for a very specific case I am working on which may drop this to ~field-high:
1) naming a device in MAAS (e.g. nvme9n1p1 -> optane);
2) creating a whole-disk partition (which results in a partition table with a partition UUID being created);
3) deploying a node.
This results in a partition uuid-based symlink (no device symlink though) being created by curtin.
Using this as a workaround may only work for ceph-volume-based charm-ceph-osd deployments where it does not matter if a device special file is a partition or the whole device as LVM is used to slice it into chunks.
I will update this bug accordingly if I am able to work with that.
I may have found a workaround for a very specific case I am working on which may drop this to ~field-high:
1) naming a device in MAAS (e.g. nvme9n1p1 -> optane);
2) creating a whole-disk partition (which results in a partition table with a partition UUID being created);
3) deploying a node.
This results in a partition uuid-based symlink (no device symlink though) being created by curtin.
$ ls -al /dev/disk/by-dname/ | grep nvme
lrwxrwxrwx 1 root root 15 Jul 23 12:08 optane-part1 -> ../../nvme9n1p1
Using this as a workaround may only work for ceph-volume-based charm-ceph-osd deployments where it does not matter if a device special file is a partition or the whole device as LVM is used to slice it into chunks.
I will update this bug accordingly if I am able to work with that.