Create a new GCP udev rules test

[ravanelli]

Describe the enhancement

After we got coreos/fedora-coreos-config#2336 merged, we now need some tests to validate if the rules are ok when working with disks. It should only run in GCP.

System details

GCP

Additional information

No response

[travier]

Would be good to land with coreos/fedora-coreos-config#2350 so that the test directly validates the change in the PR.

[travier]

A first step would be to create a test that verifies that the files exists in the image and the initrd.

Then we could create a new GCP specific test to verify that those rules work in the Platform.

[ravanelli]

@travier I saw we already have something in kola for it, so I added it in this PR coreos/fedora-coreos-config#2385

[HuijingHei]

To add kola tests for gcp, need to create confidential vm which needs to pass --confidential-compute --maintenance-policy=terminate to gcloud, should I add related option to kola (like gcp-machinetype)?

[jlebon]

Adding CLI support for it would be good indeed (for developers).

For tests, rather than a switch (because that would imply we'd need to run it separately from the other tests), my suggestion is to add a tag like confidential in the external test that kola picks up on and knows to provision the appropriate kind of system. It can error out if the conditional tag was given but the target platform != gcp (but I think in the future we may have similar modes on other clouds as well?).

[HuijingHei]

SGTM, thanks @jlebon for the pointer. CLI support PR: coreos/coreos-assembler#3474

For external test, start confidential vm on gcp and check /dev/disk/by-id/google-${ID_SERIAL_SHORT} exists, is this enough?

# bash /usr/lib/udev/google_nvme_id -d /dev/nvme0n2
ID_SERIAL_SHORT=pvc-43993288-5991-44fc-baee-2e6c1194c4de
ID_SERIAL=Google_PersistentDisk_pvc-43993288-5991-44fc-baee-2e6c1194c4de
# ls -l /dev/disk/by-id/google-pvc-43993288-5991-44fc-baee-2e6c1194c4de

Refer to https://issues.redhat.com/browse/OCPBUGS-7582?focusedId=22272502&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-22272502

[jlebon]

SGTM, thanks @jlebon for the pointer. CLI support PR: coreos/coreos-assembler#3474

For external test, start confidential vm on gcp and check /dev/disk/by-id/google-${ID_SERIAL_SHORT} exists, is this enough?

# bash /usr/lib/udev/google_nvme_id -d /dev/nvme0n2
ID_SERIAL_SHORT=pvc-43993288-5991-44fc-baee-2e6c1194c4de
ID_SERIAL=Google_PersistentDisk_pvc-43993288-5991-44fc-baee-2e6c1194c4de
# ls -l /dev/disk/by-id/google-pvc-43993288-5991-44fc-baee-2e6c1194c4de

Refer to issues.redhat.com/browse/OCPBUGS-7582?focusedId=22272502&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-22272502

Based on the discussions in the Jira ticket, it does seem like google-${ID_SERIAL_SHORT} is the only symlink expected to be created in this case.

Looking at the udev rule, the test you did exercised this rule: https://github.com/GoogleCloudPlatform/guest-configs/blob/512f7af07185041c604c3b6d9cf9ceccb5630c7d/src/lib/udev/rules.d/65-gce-disk-naming.rules#L33. There is also another rule that calls out to google_nvme_id for ephemeral local SSD disks: https://github.com/GoogleCloudPlatform/guest-configs/blob/512f7af07185041c604c3b6d9cf9ceccb5630c7d/src/lib/udev/rules.d/65-gce-disk-naming.rules#L27.

Its implementation uses a different code path in the script, so it'd be good to sanity-check that this rule is also functioning correctly by bringing up an instance with a local SSD attached.

[HuijingHei]

it'd be good to sanity-check that this rule is also functioning correctly by bringing up an instance with a local SSD attached.

Attach a local SSD to confidential vm on gcp, and check the related symlinks,
/dev/nvme0n1 is local ssd disk, and has the expected symlink google-${ID_SERIAL_SHORT}

~]# bash /usr/lib/udev/google_nvme_id -d /dev/nvme0n1
ID_SERIAL_SHORT=local-nvme-ssd-0
ID_SERIAL=Google_EphemeralDisk_local-nvme-ssd-0
~]# ls -l /dev/disk/by-id/google-local-nvme-ssd-0
lrwxrwxrwx. 1 root root 13 May 16 05:55 /dev/disk/by-id/google-local-nvme-ssd-0 -> ../../nvme0n1

/dev/nvme1n1 is nvme disk, and does not have expected symlink google-${ID_SERIAL_SHORT}, this is expected as the issue is not fixed yet.

~]# bash ./google_nvme_id -d /dev/nvme1n1
./google_nvme_id: line 65: warning: command substitution: ignored null byte in input
ID_SERIAL_SHORT=persistent-disk-0
ID_SERIAL=Google_PersistentDisk_persistent-disk-0
~]# ls /dev/disk/by-id/google-persistent-disk-0
ls: cannot access '/dev/disk/by-id/google-persistent-disk-0': No such file or directory

Maybe I can add 1 test (attach a local SSD to confidential vm) and check the 2 nvme disks symlinks, but there is another problem that current CLI only supports PERSISTENT disk, this mean I should add CLI to support?