Azure: Add predictable symlinks for secondary disks

[stereobutter]

Similar to #1122 symlinks for secondary disks on azure are not stable. From what I can gather from trial an error there are /dev/disk/azure/resource and /dev/disk/azure/root where it appears /dev/disk/azure/root always references the boot disk correctly however /dev/disk/azure/resource is randomly assigned to any one of the secondary disks (including the temporary disk that every VM gets)

lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   32G  0 disk
└─sda1   8:1    0   32G  0 part /var
sdb      8:16   0   32G  0 disk
├─sdb1   8:17   0    1M  0 part
├─sdb2   8:18   0  127M  0 part
├─sdb3   8:19   0  384M  0 part /boot
└─sdb4   8:20   0 31.5G  0 part /sysroot/ostree/deploy/fedora-coreos/var
                                /usr
                                /etc
                                /
                                /sysroot
sdc      8:32   0    7G  0 disk
└─sdc1   8:33   0    7G  0 part

where sda is a secondary disk I attached to the VM (to place /var on it via ignition), sdb the boot disk and sdc the temporary disk attached by azure.

looking at the symlinks gives

ls -la /dev/disk/*/*
lrwxrwxrwx. 1 root root  9 Apr 12 16:59  /dev/disk/azure/resource -> ../../sdc
lrwxrwxrwx. 1 root root 10 Apr 12 16:59  /dev/disk/azure/resource-part1 -> ../../sdc1
lrwxrwxrwx. 1 root root  9 Apr 12 16:59  /dev/disk/azure/root -> ../../sdb
...

What I'd actually like to to is place the user data on another disk via ignition so that I can backup that disk separately and in case disaster hits I can create a new VM with a snapshot of that disk (using wipe_table: false for that device).

[stereobutter]

Thank you a lot for you patience 🙇
Using /dev/disk/by-partlabel/user_data for the filesystem worked as expected 🥳

If you can perhaps point me in the right direction, I'd be happy to try and contribute using the WALA udev rules for azure disks either in the docs or directly in the fcos images for azure. What do you think?

[bgilbert]

Contributions are welcome if you're able to help! Ideally the rules would be included in a Fedora package that we could ship. Failing that, we could consider shipping them directly in fedora-coreos-config. I don't think the docs are a good way to proceed, especially since any udev rules specified via Ignition config don't take affect until after Ignition runs.

[dustymabe]

Regarding udev rules we already include the WALinuxAgent RPM in FCOS and have some glue to copy the udev rules into the initramfs.

One problem I see is that the RPM is a bit out of date with the latest release so maybe we just need to get the maintainer to bump things? --> Open BZ requesting new release be built: https://bugzilla.redhat.com/show_bug.cgi?id=2040980

[jlebon]

The nuclear workaround for this is documented for now at https://github.com/openshift/os/blob/master/docs/faq.md#q-how-do-i-configure-a-secondary-block-device-via-ignitionmc-if-the-name-varies-on-each-node.