-
Bug
-
Resolution: Done-Errata
-
Normal
-
4.15.0
-
Low
-
No
-
3
-
OCPEDGE Sprint 249
-
1
-
False
-
-
Previously, LVMCluster contained an excluded status element for a device that is set up correctly. This fix filters the correctly set device from being considered for an excluded status element, so it only appears in the ready devices.
-
Bug Fix
-
Done
LVMCluster starting with 4.15.0 uses the LVMVolumeGroupNodeStatus to filter for existing volumegroups that are setup on a device mapper device to verify if this device already exists. This check is now vulnerable to symlink resolution since the name of the device in the LVMVolumeGroupNodeStatus is not resolved and is compared to a resolved device name. This leads to the fact that the device is being considered available and then passed to the filters. The filters also do not resolve the sym link path so the valid FS Type check is skipped.
Version-Release number of selected component (if applicable):{code:none}
4.15.0+
How reproducible:
100% with device mapper devices (e.g. multipath, RAID via mdadm, LUKS)
Steps to Reproduce:
1. Create LVMCluster with any device mapper configuration 2. Verify LVMCluster is Ready but also contains an excluded status element
Actual results:
LVMCluster contains an excluded status element for a device that is setup correctly
Expected results:
LVMCluster should not have any excluded status element since it should be able to identify that it has already been setup or it should be able to identify that the device is not invalid
Additional info:
Symlink Missing in Status Resolution: https://github.com/openshift/lvm-operator/blob/37fb1db45a998c5f4d284c85f316a4ebafb5e185/internal/controllers/vgmanager/devices.go#L208
isDeviceAlreadyPartOfVG makes sure the device is not considered if it is known to have been setup in advance.
Symlink Missing in Status Setting: https://github.com/openshift/lvm-operator/blob/d7f215bc5f462a44dcdf8639f53bb545fd3a97b5/internal/controllers/vgmanager/status.go#L175
setDevices uses PVNames without Symlink resolution so they cannot be relied on to determine blockdevice identification without checking symlinks first (this is okay, as we dont want to store symlink data in status messages since they might change)
Even if the Status resolution returns the device, there should be a filter against this, but the filter also does not resolve the symlink:
https://github.com/openshift/lvm-operator/blob/d7f215bc5f462a44dcdf8639f53bb545fd3a97b5/internal/controllers/vgmanager/filter/filter.go#L105
- clones
-
OCPBUGS-29188 LVMCluster tries to filter already used devices if they are symlinked and causes Status Messages to be present
- Closed
- depends on
-
OCPBUGS-29188 LVMCluster tries to filter already used devices if they are symlinked and causes Status Messages to be present
- Closed
- links to
-
RHBA-2024:128370 LVMS 4.15.1 Bug Fix Update