Bug 1696860

Summary: containerized ceph-volume batch fails while waiting for records from udev
Product: [Red Hat Storage] Red Hat Ceph Storage Reporter: John Fulton <johfulto>
Component: Ceph-AnsibleAssignee: Guillaume Abrioux <gabrioux>
Status: CLOSED ERRATA QA Contact: ceph-qe-bugs <ceph-qe-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.2CC: adeza, alsilva, aschoen, ceph-eng-bugs, ceph-qe-bugs, dhill, evelu, fandrade, gabrioux, gmeno, johfulto, nthomas, sankarshan, vashastr, wrosalem
Target Milestone: rc   
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ceph-ansible-3.2.8-1.el7cp.noarch Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-18 04:36: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:
Bug Depends On:    
Bug Blocks: 1578730    
Attachments:
Description Flags
ceph-volume.log none

Description John Fulton 2019-04-05 19:02:47 UTC
Created attachment 1552681 [details]
ceph-volume.log

As per a report from a consultant deploying OSP13/RHCS3.2 with bluestore, ceph-volume batch, as executed in a container by ceph-ansible, encountered the symptoms of bug 1676612. See attached cinder log (and snippet [2]). 

The fixed-in of bug 1676612, lvm2-2.02.184-1.el7, is not yet in the latest ceph-container rhceph/rhceph-3-rhel7 [1] at this time, 3-23. 

Could a new rhceph/rhceph-3-rhel7 container be released containing lvm2-2.02.184-1.el7 or newer? 

  John

[1] https://access.redhat.com/containers/?tab=overview#/registry.access.redhat.com/rhceph/rhceph-3-rhel7

[2] 
[root@overcloud-computehci-0 heat-admin]# cat /var/log/ceph/ceph-volume.log 
[2019-04-04 19:18:33,932][ceph_volume.main][INFO  ] Running command: ceph-volume --cluster ceph lvm batch --bluestore --yes --prepare /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt /dev/nvme0n1 /dev/nvme1n1 --report --format=json
[2019-04-04 19:18:33,949][ceph_volume.process][INFO  ] Running command: /usr/sbin/lvs --noheadings --readonly --separator=";" -o lv_tags,lv_path,lv_name,vg_name,lv_uuid,lv_size
[2019-04-04 19:26:46,782][ceph_volume.process][INFO  ] stderr WARNING: Device /dev/nvme1n1 not initialized in udev database even after waiting 10000000 microseconds.
[2019-04-04 19:26:46,782][ceph_volume.process][INFO  ] stderr WARNING: Device /dev/sda not initialized in udev database even after waiting 10000000 microseconds.
[2019-04-04 19:26:46,782][ceph_volume.process][INFO  ] stderr WARNING: Device /dev/sdq not initialized in udev database even after waiting 10000000 microseconds.
[2019-04-04 19:26:46,782][ceph_volume.process][INFO  ] stderr WARNING: Device /dev/nvme0n1 not initialized in udev database even after waiting 10000000 microseconds.

Comment 8 John Fulton 2019-04-18 01:06:52 UTC
ceph-ansible 3.2.4-1

Comment 10 John Fulton 2019-04-18 04:36:02 UTC
Upgrading to ceph-ansible 3.2.8 fixed this issue.