kubeapi for matching pv/pvc to /dev/sd devices #4378
Conversation
andrewd-zededa
force-pushed
the
kubeapi-diskmetric
branch
from
0e8ed65 to
3bf395b
Compare
| } | ||
|
|
||
| for _, devEnt := range blockDevs { | ||
| if !strings.HasPrefix(devEnt.Name(), "sd") { |
There was a problem hiding this comment.
@andrewd-zededa , why are you considering only sdX devices? What about devices that have NVMes that will be named into something like nvme0n1, nvme0n1p1, nvme0n1p2, nvme0n1p3?
There was a problem hiding this comment.
And also eMMCs, that in this case will be named as something like mmcblk0p1, mmcblk0p2, etc...
There was a problem hiding this comment.
@rene this is filtering to only sdX devices as those are the only type which are presented as virtual frontend block devices by the longhorn engine we are using currently. I see your point though and this function could be opened up to build a map of all block devices or allow a filter passed in as a parameter to control the size of the map.
This will be used in an upcoming PR to create DiskMetric objects for cluster PVCs. Signed-off-by: Andrew Durbin <[email protected]>
|
I'm readying an updated commit with a fix found in testing this path. |
andrewd-zededa
force-pushed
the
kubeapi-diskmetric
branch
from
3bf395b to
4462d95
Compare
|
Updated with the latest from the poc-oct03-2024 branch which resolves a problem where IsDir DiskMetrics were incorrectly unpublished. I need to verify the new test runs before further review. |
This will be used in an upcoming PR to create DiskMetric objects for cluster PVCs.
When a cluster volume is created it will show on the controller as the PVC name. This PVC(PersistentVolumeClaim) has a linked PV(PersistentVolume) which is the name of a block device under /dev/longhorn/ which itself shares the same major:minor pair as one /dev/sdX device. Volumemgr will use this API to map from PVC->PV->/dev/sdX device to link from existing sdX DiskMetric object to a cluster volume DiskMetric if it is currently attached on this node.