Bug 1862489 - LSO autoprovisioning should exclude top level disks that are part of LVM volume group.
Summary: LSO autoprovisioning should exclude top level disks that are part of LVM volu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 4.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.7.0
Assignee: Rohan CJ
QA Contact: Chao Yang
URL:
Whiteboard:
: 1886835 (view as bug list)
Depends On:
Blocks: 1886835
TreeView+ depends on / blocked
 
Reported: 2020-07-31 14:25 UTC by Rohan CJ
Modified: 2021-02-24 15:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1886835 (view as bug list)
Environment:
Last Closed: 2021-02-24 15:14:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift local-storage-operator pull 155 0 None closed Bug 1862489: LSO autoprovisioning should exclude top level disks that are part of LVM volume group 2021-01-18 08:30:33 UTC
Red Hat Product Errata RHSA-2020:5633 0 None None None 2021-02-24 15:14:42 UTC

Description Rohan CJ 2020-07-31 14:25:42 UTC
Description of problem:

Currently, LSO does not check if a block device is a LVM PV before creating a PV based on it. 

LVM is also not accepted as valid input to LocalVolumeSet.spec.devicTypes.

LocalVolumeDiscoveryResult also needs to display that a device is claimed by lvm

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:

Device discovery should/filter report devices claimed as LVM PVs (Physical Volumes)
Device provisioning should allow creation of PVs based on lvm type disks.


Master Log:

Node Log (of failed PODs):

PV Dump:

PVC Dump:

StorageClass Dump (if StorageClass used by PV/PVC):

Additional info:

Comment 4 Chao Yang 2020-10-09 10:07:27 UTC
1.oc get pv
NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
local-pv-af4ec62b   2Gi        RWO            Delete           Available           lvs                     3m46s
local-pv-e20c5fa6   5Gi        RWO            Delete           Available           lvs                     3m46s

2.
oc get pv local-pv-af4ec62b -ojson | jq .spec.local
{
  "path": "/mnt/local-storage/lvs/nvme-Amazon_Elastic_Block_Store_vol005f87b58241cba06-part1"
}

3.
lsblk -o +FSTYPE
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT FSTYPE
nvme0n1                      259:0    0   120G  0 disk            
|-nvme0n1p1                  259:1    0   384M  0 part /boot      ext4
|-nvme0n1p2                  259:2    0   127M  0 part /boot/efi  vfat
|-nvme0n1p3                  259:3    0     1M  0 part            
`-nvme0n1p4                  259:4    0 119.5G  0 part            crypto_LUKS
  `-coreos-luks-root-nocrypt 253:0    0 119.5G  0 dm   /sysroot   xfs
nvme1n1                      259:5    0     5G  0 disk            
`-nvme1n1p1                  259:6    0     2G  0 part            LVM2_member
  `-vgpool-lvstuff           253:1    0     1G  0 lvm             

4.
lrwxrwxrwx. 1 root root 15 Oct  9 09:47 nvme-Amazon_Elastic_Block_Store_vol005f87b58241cba06-part1 -> ../../nvme1n1p1

5.
oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.6.0-0.nightly-2020-10-08-210814   True        False         7h30m   Cluster version is 4.6.0-0.nightly-2020-10-08-210814


oc get csv
NAME                                           DISPLAY         VERSION                 REPLACES   PHASE
local-storage-operator.4.6.0-202010061132.p0   Local Storage   4.6.0-202010061132.p0              Succeeded

Comment 7 Chao Yang 2020-10-10 10:12:32 UTC
If prepare the disk first like below:
nvme1n1                      259:5    0    10G  0 disk            
`-nvme1n1p1                  259:7    0     2G  0 part            LVM2_member
  `-vgpool-lvstuff           253:1    0     1G  0 lvm             

Then create localvolumeset, there is no pv provisioned for disk nvme1n1p1.

Comment 8 Chao Yang 2020-10-10 10:13:46 UTC
Update this bz status based on #7
Will track issue https://bugzilla.redhat.com/show_bug.cgi?id=1862489#c4 in other bugs.

Comment 9 Rohan CJ 2020-10-12 07:43:03 UTC
Comment 7 seems to indicate that the behaviour is correct. Was Comment 4 differently run?

Was the disk made part of a VG after provisioning in the Comment 4 run? -> This can't be helped, the LSO 
Or was the PV created using a LocalVolume? -> This feature is only for auto-provisioning (localvolumeset)

Comment 10 Rohan CJ 2020-10-12 07:45:48 UTC
Typo fix, dropped half a sentence:

Was the disk made part of a VG after provisioning in the Comment 4 run? -> This can't be helped, the LSO can't help anything after the PV is provisioned.

Comment 11 Chao Yang 2020-10-13 06:47:34 UTC
Update the bz status

Comment 12 Sahina Bose 2020-10-13 06:51:47 UTC
Change target release to 4.6.0?

Comment 13 Tomas Smetana 2020-10-19 11:07:46 UTC
Thanks everyone! Seems like it's all set in the end.

Comment 14 Rohan CJ 2020-11-02 10:45:46 UTC
*** Bug 1886835 has been marked as a duplicate of this bug. ***

Comment 17 errata-xmlrpc 2021-02-24 15:14:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:5633


Note You need to log in before you can comment on or make changes to this bug.