Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1600856

Summary:	[RFE] There should be an easy way to skip/blacklist a missing ceph disk when updating/upgrading the overcloud
Product:	Red Hat OpenStack	Reporter:	Eduard Barrera <ebarrera>
Component:	rhosp-director	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED DUPLICATE	QA Contact:	Amit Ugol <augol>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	14.0 (Rocky)	CC:	dbecker, johfulto, mburns, morazi
Target Milestone:	---
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:	2018-07-13 12:24:36 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 Eduard Barrera 2018-07-13 08:15:01 UTC

Description of problem:

Since OSP12 we have blacklists, skipping the whole update/upgrade on a server. There could be situation where we have a missing disk on ceph (hardware malfunction, ... ), in that case the update/upgrade will fail.  There should be am easy way ( and have it documented ) where we can apply the updates on the ceph nodes with missing disk and have the deployment complete successfully (imagine a planned maintenance window for upgrading the environment on weekend and have to postpone it because a missing disk in the cluster)

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


How reproducible:
Situations like that already happened

Actual results:
update (and perhaps upgrade too ) fails if a disk on ceph is missing

Expected results:
Have a way to skip a missing disk

Comment 1 John Fulton 2018-07-13 12:35:35 UTC

The feature already exists as per bug 1520004 and is described in the upstream documentation already: 

https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/node_specific_hieradata.html

The gist of the document above is:

If all servers use the same disk list, but there's a subset of servers which cannot use the same disk list (), then you can use OSPd to deploy/update those servers with their own special disk list. 

I think getting this into the downstream documentation should be the next step.

*** This bug has been marked as a duplicate of bug 1520004 ***