Bug 1730541

Summary:	[ceph-validate] : lvm scenario : abort site-docker .yml if GPT headers are found on devices
Product:	[Red Hat Storage] Red Hat Ceph Storage	Reporter:	Vasishta <vashastr>
Component:	Ceph-Ansible	Assignee:	Guillaume Abrioux <gabrioux>
Status:	CLOSED ERRATA	QA Contact:	Ameena Suhani S H <amsyedha>
Severity:	high	Docs Contact:
Priority:	low
Version:	3.3	CC:	amsyedha, aschoen, assingh, ceph-eng-bugs, ceph-qe-bugs, gmeno, nthomas, tchandra, tserlin
Target Milestone:	rc
Target Release:	4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ceph-ansible-4.0.0-0.1.rc12.el8cp	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1731310 (view as bug list)		Environment:
Last Closed:	2020-01-31 12:46:52 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:

Description Vasishta 2019-07-17 05:53:05 UTC

Description of problem:
Cluster initialization failed saying "ceph-volume lvm batch: error: GPT headers found, they must be removed on: /dev/sdb". Tried a method to erase gpt headers from disk and re-initialized playbook, after running through all previous tasks again playbook failed saying the same reason.

As we have ceph-validate to per-check the feasibility of cluster creation, it would be a great improvisation from usability perspective if ceph-validate can fail playbook at early stage if GPT headers are present on a disk.

Version-Release number of selected component (if applicable):
ceph-ansible-3.2.20-1.el7cp.noarch
ceph-3.3-rhel-7-containers-candidate-14679-20190712005524

How reproducible:
Always (2/2)

Steps to Reproduce:
1. Make sure that you have gpt headers on disks meant to have OSD
2. Run site-docker.yml


Expected results:
ceph-validate must check whether the disk is feasible for complete OSD configuration.


Additional info:

Comment 5 Giridhar Ramaraju 2019-08-05 13:10:31 UTC

Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. 

Regards,
Giri

Comment 6 Giridhar Ramaraju 2019-08-05 13:11:33 UTC

Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. 

Regards,
Giri

Comment 9 errata-xmlrpc 2020-01-31 12:46:52 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, 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/RHBA-2020:0312