-
Notifications
You must be signed in to change notification settings - Fork 98
udev: add support for AWS EBS NVMe friendly names #268
Conversation
I could imagine other cloud providers also doing this; it's not technically specific to AWS right? Or is that hardcoded offset somehow specific to AWS? I guess my main concern boils down to: This is something we never want to do on a true physical system with real NVMe devices, as there could actually be legacy SCSI devices and we don't want to blow away their device nodes. Also I believe one could (in theory) have NVMe and SCSI devices in libvirt, although in practice people use virtio. |
This is very specific to AWS volumes, see coreos/bugs#2399. I'm not aware if/which other providers are doing similar to this. For reference, NVMe devices works perfectly fine without this, it only adds support for user-customized AWS friendly names. |
I'm okay with shipping this in |
I manually validated this on a custom AMI on |
OK. But one thing that isn't clear to me exactly; it looks like we're extracting some sort of raw header from the NVMe device based on a fixed offset; is there any chance that something else is there? Feels like we're at risk of creating random symlinks? (I could be wrong) |
@cgwalters this relies on parsing data out of the vendor-specific payload in the NVMe controller, and vendors can put whatever they want in there. For such reason, the udev rule is scoped to |
Ah, I missed that. That totally addresses my concern, thanks! |
@cgwalters on a second look, you are also right because not all the rules are scoped on that. I should fix that, thanks! |
Maybe simplest to check the model in the script too? |
After the last round of discussion, I amended and re-tested this on AWS. udev rules are now all matching on AWS-EBS model, and the script itself also checks that it is being run by udev on an EBS device. PTAL. |
How does one track which version of Container Linux this will make? |
@george-angel It's already released in 1828.0.0, the current alpha. |
Ref: coreos/bugs#2399
Note: while this is AWS-specific, the payload is so small and the lack of updates for OEM partition scares me, so I'm proposing to add it here instead of a new OEM-specific ebuild.