Description of problem: I've run into LVM errors due to the global_filter parameter in /etc/lvm/lvm.conf Actual results: With the current filter: global_filter = "[ r|^/dev/disk/by-path/ip.*iscsi.*\.org\.openstack:.*| ]" It results in the following error for LVM commands: [root@osp10 ~]# lvdisplay Invalid filter pattern "[ r|^/dev/disk/by-path/ip.*iscsi.*\.org\.openstack:.*| ]". Failed to create global regex device filter Expected results: I think the filter is meant to be: global_filter = [ "r|^/dev/disk/by-path/ip.*iscsi.*\.org\.openstack:.*|" ] (with quotes inside the brackets) This results in successful LVM commands: [root@osp10 ~]# lvdisplay --- Logical volume --- LV Path /dev/rhel/swap LV Name swap VG Name rhel LV UUID TodDQO-LMp7-VTOE-bA3B-fDeD-TFUp-UedwvZ LV Write Access read/write LV Creation host, time localhost, 2016-09-02 13:26:19 +1000 LV Status available # open 2 LV Size 2.00 GiB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:1 --- Logical volume --- LV Path /dev/rhel/root LV Name root VG Name rhel LV UUID feHxeY-RTMj-BVOY-aha0-EMfy-r101-H8TDT8 LV Write Access read/write LV Creation host, time localhost, 2016-09-02 13:26:20 +1000 LV Status available # open 1 LV Size 50.00 GiB Current LE 12800 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:0 Additional info: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/lvm_filters.html
Asking for a blocker on this one since all the deployments where undercloud runs lvm fails. Workaround is to manually adjust /etc/lvm/lvm.conf with: global_filter = ["r|^/dev/disk/by-path/ip.*iscsi.*\.org\.openstack:.*|"] and rerun openstack undercloud install
Jeff, was this the same bug you fixed upstream? If so, can you check if that is in the OSP10 packaging yet?
Yes, this is the same bug (and seems to be the same as bug 1323024). I checked in dist-git and the tarball containing the fix is: instack-undercloud-5.0.0.0b4.dev7-0.20160907134010.649dc3f-649dc3f4b9af704ffb230a06435ac21e3b800a75.tar.gz
(In reply to Jeff Peeler from comment #4) > Yes, this is the same bug (and seems to be the same as bug 1323024). I > checked in dist-git and the tarball containing the fix is: > > instack-undercloud-5.0.0.0b4.dev7-0.20160907134010.649dc3f- > 649dc3f4b9af704ffb230a06435ac21e3b800a75.tar.gz ok great, thanks. can you set the Fixed in Version and move the bug to MODIFIED?
Tested using: instack-undercloud-5.0.0-0.20160907134010.649dc3f.el7.centos.noarch.rpm Verification flow: [root@controller-0 ~]# lvdisplay --- Logical volume --- LV Path /dev/cinder-volumes/volume-09d0721d-da43-409d-820a-4701cde59714 LV Name volume-09d0721d-da43-409d-820a-4701cde59714 VG Name cinder-volumes LV UUID 4Rj0cz-dQ4o-84wo-y3vy-3z4D-ZEb3-GTcfc5 LV Write Access read/write LV Creation host, time controller-0.localdomain, 2016-09-29 08:48:57 +0000 LV snapshot status source of _snapshot-82cb3c6e-b2bc-40ea-a306-de1f9e5ead7a [active] LV Status available # open 0 LV Size 1.00 GiB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:1 --- Logical volume --- LV Path /dev/cinder-volumes/_snapshot-82cb3c6e-b2bc-40ea-a306-de1f9e5ead7a LV Name _snapshot-82cb3c6e-b2bc-40ea-a306-de1f9e5ead7a VG Name cinder-volumes LV UUID ovrI1T-J1HE-6XCk-kw7w-ppY7-3IDU-icJio8 LV Write Access read/write LV Creation host, time controller-0.localdomain, 2016-09-29 13:00:56 +0000 LV snapshot status active destination for volume-09d0721d-da43-409d-820a-4701cde59714 LV Status available # open 0 LV Size 1.00 GiB Current LE 256 COW-table size 1.00 GiB COW-table LE 256 Allocated to snapshot 0.00% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:3
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, 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://rhn.redhat.com/errata/RHEA-2016-2948.html