[enhancement] Allow / Choose a way to tell cc_mounts.py to use UUID for the entries added to fstab

Dr-Shadow commented 7 months ago

Problem

On our systems, we have found that relying on /dev/sdX paths is not reliable and have tried various workarounds to avoid issues.

The solution we have recently implemented is to use the path provided in /dev/disk/by-id/. This has been working well so far.

However, we would prefer to rely on the disk's UUID, and the fstab is populated by cc_mounts.py, which we don't have much control over through configuration.

Would it be possible to provide a configuration option to use the newly created disk's UUID instead of the path ?

Configuration sample

device_aliases: 
  disk-os: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0
  swap: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1
disk_setup:
  disk-os:
    table_type: gpt
    overwrite: false
  swap:
    table_type: gpt
    layout: [[100, 82]]
    overwrite: true
fs_setup:
  - device: swap
    filesystem: swap

This is how the fstab entry is filled :

<TIMESTAMP> - cc_mounts.py[DEBUG]: Changes to fstab: ['+ /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part1 none swap sw,comment=cloudconfig 0 0']

Additional note

If UUIDs are not reliable either, would it be possible to at least provide an alternative ?

Closure

Thank you for considering this feature request. We appreciate your time and effort in improving cloud-init.

Dr-Shadow commented 7 months ago

Possibly related to this issue which is relating multiple problems : #4920

holmanb commented 7 months ago

@Dr-Shadow Thanks for reporting!

Yes, this is another facet of the issue filed in #4920. Writing out labels to fstab wasn't explicitly mentioned in #4920, but it's something cloud-init should grow the ability to do. I may get some time in the next cycle to work on this.

jichenjc commented 4 months ago

https://github.com/canonical/cloud-init/issues/5528 might be related as well?

ggjulio commented 4 months ago

Hey @Dr-Shadow , I'm having the same issue and was thinking of using /dev/by-uuid/

This current config don't work yet ?

device_aliases: 
  some-alias: /dev/disk/by-id/${UUID}

If not, how did you implemented it ?

Dr-Shadow commented 4 months ago

Hey @Dr-Shadow , I'm having the same issue and was thinking of using /dev/by-uuid/

This current config don't work yet ?
device_aliases: 
  some-alias: /dev/disk/by-id/${UUID}
If not, how did you implemented it ?

On my systems the /dev/disk/by-id is more predictable than /dev/disk/by-uuid

For example : /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0

So I guess I didn't use it because the UUID is known only after formatting (which is why it is less predictable unless supported directly from cloud-init)

canonical / cloud-init