Enable AWS to use fixed block device pathnames#50
Merged
chucklever merged 4 commits intomainfrom Oct 20, 2025
Merged
Conversation
AWS EBS volumes do not have consistent names across reboots. Sometimes the root is /dev/nvme0n1; sometimes it can be /dev/nvme2n1. The data device is likewise flaky. So, unlike with libvirt, a device pathname cannot be soldered into a .config and be expected to work reliably. To make sure that EBS volumes are always accessible via a consistent device name, add a tag to each extra volume created by terraform, and use a udev script to link that device under /dev/disk/kdevops. That way, the pathname "/dev/disk/kdevops/extra-volume-00" can always refer to /data on all instances and in our .config files. Assisted-by: Claude AI Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Now that all cloud providers have consistent device pathnames for the extra volumes created by terraform, we can make setting the "data" and "sparse" device names consistent as well. These symbolic constants can then be used by the volume_group and devconfig playbooks and the fstests workflow to reliably locate their block device resources on test runners in the cloud. Follow the design of the OCI provider and expose the device pathnames for the data and sparse device so these pathnames can be used reliably by other kdevops subsystems. Note that the AWS data volume default, which was hidden in the Kconfig menu, changes from "/dev/nvme1n1" to "/dev/disk/kdevops/extra-volume-00." Existing AWS configurations might break if they depend on the old pathname. Also, "make menuconfig" by itself does not change the existing value of TERRAFORM_AWS_DATA_VOLUME_DEVICE_FILE_NAME to the new string. Users must make that adjustment manually in existing defconfig files. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
The cloud provider settings now consistently provide the correct device pathnames for the /data and sparse devices. Set up the default pathname for the fstests sparse device properly for those cases. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Thanks to recent commits, the volume_groups role can now use
{{ data_device }} for AWS just like it does for other cloud
providers.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AWS EBS volumes do not have consistent names across reboots. Sometimes the root is /dev/nvme0n1; sometimes it can be /dev/nvme2n1. The data device is likewise flaky.
So, unlike with libvirt, a device pathname cannot be soldered into a .config and be expected to work reliably.
To make sure that EBS volumes are always accessible via a consistent block device name, add a tag to each extra volume created by terraform, and use a udev script to link that device under /dev/disk/kdevops. That way, the pathname "/dev/disk/kdevops/extra-volume-00" can always refer to /data on all instances and in our .config files.