Bug 2144400
| Summary: | TopoLVM on SNO is using a PV while its status is "Available" | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat OpenShift Data Foundation | Reporter: | Jenia Peimer <jpeimer> |
| Component: | topolvm | Assignee: | N Balachandran <nibalach> |
| Status: | CLOSED NOTABUG | QA Contact: | Shay Rozen <srozen> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.11 | CC: | akalenyu, muagarwa, nigoyal, ocs-bugs, odf-bz-bot, rsinghal |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-22 11:12:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Please elaborate on the use case. Topolvm is not supposed to be used with LSO. To elaborate - odf lvmo directly uses the disks on the system - it is not aware of or using the PV created by LSO and does not use it as a PV. You can either use LSO or ODF LVMO. They are not meant to be used together. I'm still concerned about the current behavior. Imagine the customers who make their own PVs instead of using LSO. How surprised will they be when something under the hood grabs those disks. @sapillai, wdyt? (In reply to Jenia Peimer from comment #4) > I'm still concerned about the current behavior. > Imagine the customers who make their own PVs instead of using LSO. How > surprised will they be when something under the hood grabs those disks. > That is not the use case LVMO is targeting. If customers are creating PVs from the local disks, they should not be using LVMO. ODF LVMO is an alternative to LSO which allows dynamic provisioning of local storage. As such this is working as expected. LVMO is assumed to be the only storage provisioner on the cluster in this case. Closing as not a bug. I forgot to explain the storagecapacity: The deviceclass configuration is: overprovisionRatio: 10 sizePercent: 90 This means the available storage is (90/100) * (vg size = 446) * 10 = ~4014 GB There are some LVs created already which total about 181 G So the capacity = 4014 - 181 = 3833 G which is close to the value the csistoragecapacity shows. |
Description of problem (please be detailed as possible and provide log snippests): TopoLVM is using a PV (created by LSO) while its status is "Available". TopoLVM's Storage Capacity doesn't match the PV size. Version of all relevant components (if applicable): odf-lvm-operator.v4.11.3 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? We still can run Openshift Virtualization VMs. Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 2 Can this issue be reproducible? Yes Can this issue reproduce from the UI? Haven't tried If this is a regression, please provide more details to justify this: No Steps to Reproduce: 1. SNO Bare metal - deploy OCP 4.12 2. Deploy LSO - it created a PV of 446 Gi 3. Deploy TopoLVM - *odf-lvm-operator.v4.11.3* apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: finalizers: - lvmcluster.topolvm.io name: odf-lvmcluster namespace: openshift-storage spec: storage: deviceClasses: - name: vg1 thinPoolConfig: name: thin-pool-1 overprovisionRatio: 10 sizePercent: 90 Actual results: $ oc get pv local-pv-74b43d87 -o yaml | grep -e Available -e sdb storage.openshift.com/device-name: sdb phase: Available TopoLVM is using the LSO PV while PV is shown "Available" [core@cnv-qe-infra-24 ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1G 0 loop sda 8:0 0 558.4G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 127M 0 part ├─sda3 8:3 0 384M 0 part /boot └─sda4 8:4 0 557.9G 0 part /sysroot sdb 8:16 0 446.6G 0 disk ├─vg1-thin--pool--1_tmeta 253:0 0 52M 0 lvm │ └─vg1-thin--pool--1-tpool 253:2 0 401.9G 0 lvm │ ├─vg1-thin--pool--1 253:3 0 401.9G 1 lvm │ ├─vg1-e657234e--2317--4733--9ecf--7d420d91478c 253:4 0 1G 0 lvm │ ├─vg1-cad5e45e--b904--4052--ba8c--bf3fa7a365b3 253:5 0 30G 0 lvm │ ├─vg1-ecd4c764--fcd6--4539--b2a2--592c4aa6e036 253:6 0 30G 0 lvm │ ├─vg1-b87911a2--09a0--44c5--be5f--ba262a1874ac 253:7 0 30G 0 lvm │ ├─vg1-b4c3e700--dd41--4a14--8d44--6b62d9bdbed2 253:8 0 30G 0 lvm │ ├─vg1-64ed3ffa--65dc--4db6--a856--d53e2e8fa364 253:9 0 30G 0 lvm │ └─vg1-1c8f10fc--7387--402d--8c8a--baf0fd45e186 253:10 0 30G 0 lvm └─vg1-thin--pool--1_tdata 253:1 0 401.9G 0 lvm └─vg1-thin--pool--1-tpool 253:2 0 401.9G 0 lvm ├─vg1-thin--pool--1 253:3 0 401.9G 1 lvm ├─vg1-e657234e--2317--4733--9ecf--7d420d91478c 253:4 0 1G 0 lvm ├─vg1-cad5e45e--b904--4052--ba8c--bf3fa7a365b3 253:5 0 30G 0 lvm ├─vg1-ecd4c764--fcd6--4539--b2a2--592c4aa6e036 253:6 0 30G 0 lvm ├─vg1-b87911a2--09a0--44c5--be5f--ba262a1874ac 253:7 0 30G 0 lvm ├─vg1-b4c3e700--dd41--4a14--8d44--6b62d9bdbed2 253:8 0 30G 0 lvm ├─vg1-64ed3ffa--65dc--4db6--a856--d53e2e8fa364 253:9 0 30G 0 lvm └─vg1-1c8f10fc--7387--402d--8c8a--baf0fd45e186 253:10 0 30G 0 lvm TopoLVM's Storage Capacity doesn't match the PV size $ oc get csiStorageCapacity -n openshift-storage csisc-78wcw -oyaml | grep capacity capacity: 3929656Mi 3929656 Mi / 1024 = 3837 Gi (while LSO PV is 446 Gi) Expected results: If TopoLVM is using a PV, PV shouldn't be marked as "Available". csiStorageCapacity should show me the real storage capacity.