New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support other options besides device names since those change across reboots #1228
Comments
Bump. I have had the same issue and would really like to use |
I too would like to be able to use |
@mhulsher I forgot to update my response in this issue. I talked with the devs on slack and I looks like rook uses the |
The issue of device names changing across reboots was addressed in the cluster update design doc at https://github.com/rook/rook/blob/master/design/cluster-update.md#device-name-changes However, also adding support for |
I'd love to see /dev/disk/by-path/ IIRC, on my server the SAS expander backplane or the HBA has limits on mixing SAS / SATA, ssd/hdd drives. Specifically bays 0-1 are supposed to be the two used for cache drives when mixing types. It would be great to be able to set metadata to the /dev/disk/by-path/ for those 2 bays and storage to the paths for the other 10. Not sure if newer hardware has similar issues with NVMe / SAS / SATA / etc. |
Even ignoring reboots, being able to reference backing disks by stable device names would be very useful, particularly for environments where the disks may be attached dynamically, and (along with rook) programmatically. |
As described in https://github.com/rook/rook/blob/master/design/multiple-storage-types-support.md#storagescopespec, a user should be able to use the StorageScopeSpec to select devices not just by name, but other more persistent properties such as |
Once rook stats using ceph-volume, this will not be a problem since LVM takes care of matching a device to its logical volume name |
Honestly an even better idea would be to rely on Kubernetes volumes and block devices which would make the whole detection and identity thing just go away. Security-wise it's also pretty nice since it woud forego the requirement to have any sort of privileged access. I'm working on a CSI ZFS provisioner which can provision local volumes and block devices which could then be used to run Rook on top of it. This would allow a nicely layered setup, some sort of local storage system for things that need local storage or can live with downtime when moving storage and distributed storage systems layered on top of that. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
/removestale |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
/removestale |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Activity! |
@mvollman Weren't you looking at configuring OSDs based on the full path for the device? I can't seem to find a related PR, but I was sure one was at least in progress. |
@travisn I am not currently looking into it. It did come up in the scope of another PR a while back, but I was unable to add the capability at that time. I will try to find time to take another look at it. |
Looks like this is released with v1.1? |
hello,it seems I met the problem too. |
Is this resolved by #4285 ? |
Rook-Ceph now supports specify device by their fullpath instead of links created by the kernel like /dev/sdb. Closes: rook#1228 Co-authored-by: Sean Micklethwaite <sean@wayve.ai> Signed-off-by: Sébastien Han <seb@redhat.com>
Rook-Ceph now supports specify device by their fullpath instead of links created by the kernel like /dev/sdb. Closes: rook#1228 Co-authored-by: Sean Micklethwaite <sean@wayve.ai> Signed-off-by: Sébastien Han <seb@redhat.com>
Rook-Ceph now supports specify device by their fullpath instead of links created by the kernel like /dev/sdb. Closes: rook#1228 Co-authored-by: Sean Micklethwaite <sean@wayve.ai> Signed-off-by: Sébastien Han <seb@redhat.com>
Rook-Ceph now supports specify device by their fullpath instead of links created by the kernel like /dev/sdb. Closes: rook#1228 Co-authored-by: Sean Micklethwaite <sean@wayve.ai> Signed-off-by: Sébastien Han <seb@redhat.com>
Rook-Ceph now supports specify device by their fullpath instead of links created by the kernel like /dev/sdb. Closes: rook#1228 Co-authored-by: Sean Micklethwaite <sean@wayve.ai> Signed-off-by: Sébastien Han <seb@redhat.com>
Since we would need this change: is a backport to 1.2 planned or will the 1.3 release be available rather soon-ish? :) |
It isn't planned for backport to 1.2. The target for 1.3 is early next week. |
Rook-Ceph now supports specify device by their fullpath instead of links created by the kernel like /dev/sdb. Closes: rook#1228 Co-authored-by: Sean Micklethwaite <sean@wayve.ai> Signed-off-by: Sébastien Han <seb@redhat.com>
Currently Rook does not work with symlinked devices (/dev/zvol, /dev/disk/by-id, LVM, ...), it requires a real device inode. This makes it hard to use on block device providers (I'm personally interested in LVM and ZFS zvol) for which these inodes are not consistent across reboots. Rook code extensively works with raw inode names, so I don't really know where support for that should be implemented.
The text was updated successfully, but these errors were encountered: