Comment 10 for bug 1735839

Andres Rodriguez (andreserl) wrote :

To better understand the context of this issue, I briefly discussed it with Dmitrii on IRC and we have identified 3 areas:

 A. Currently, we are relying on charm options to specify which storage devices to use for ceph data and journal or wal/db devices (/dev/disk/by-<logical-name-in-maas>/logicalname0 /dev/disk/by-<logical-name-in-maas>/logicalname1 and so on). That said:
 - The work around is to rename the block devices in MAAS (which renames the partition prefix and the dname symlink).
 - The desired fix is to use Juju storage instead (which is also supported by the ceph-osd charm), which would require solving [2] in MAAS.

 B. Curtin currently writes symlinks (by-dname) based on GPT partition UUIDs, partition UUIDs and other superblock identifiers. Curtin, however, doesn't create that for clean devices. As such, if curtin were to *also* create symlinks based on WWN or serial ID, it would help with the use cases. This means *this* bug applies for is valid for curtin, but invalid for MAAS.

 C. MAAS to preseed disk UUIDs for KVM pods VMs, so that when B is solved, disks would have proper symlinks. Requires a new bug to be filed for MAAS.

[2]: https://bugs.launchpad.net/maas/+bug/1713239