Bug 1305009

Summary:	cinder.conf gets overwritten on controller nodes upon redeploying an existing overcloud
Product:	Red Hat OpenStack	Reporter:	Anand Nande <anande>
Component:	rhosp-director	Assignee:	Angus Thomas <athomas>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Shai Revivo <srevivo>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0 (Kilo)	CC:	anande, athomas, dbecker, egafford, eharney, ekuvaja, gfidente, jcoufal, jraju, mburns, morazi, pgrist, rhel-osp-director-maint, sbaker, scohen, sputhenp, tshefi, yrabl
Target Milestone:	---	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-12-07 14:25:28 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:

Comment 4 Sadique Puthen 2016-02-05 11:44:03 UTC

The controllers are initially deployed with standard cinder configuration. Then the file is manually edited to integrate it with emc vnx on controllers.

Then they started scaling compute nodes gradually in this deployment. like add 2 compute nodes today, add another 2 after two more days, etc. When they scale compute nodes, some times cinder.conf on controllers gets overwritten to the default one. Some times the changes that they manually made remains without any effect.

We would like to first understand how it's actually expected works. When we scale compute nodes, is it expected that cinder.conf on controllers will always get overwritten? If yes, then why it's not overwritten during some attempts? If yes, then we should have to drive this manual change via director as a permanent solution. Right?

If it's not expected to overwrite, then why is it overwriting some time? If it's not expected to overwrite, then isn't it a bug that we need to fix?

They have put the next compute node scaling on hold to help us collect as much as details and logs. We need to tell them what logs we need to investigate if this is the bug that I mentioned earlier. They will scale and collect those logs.

Comment 5 Mike Burns 2016-02-05 12:51:16 UTC

*** Bug 1305008 has been marked as a duplicate of this bug. ***

Comment 13 Mike Burns 2016-04-07 21:07:13 UTC

This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 16 Paul Grist 2016-10-14 01:23:19 UTC

This is a bug it would be good to fix sooner than later. Adding some people that could possibly check it during other OSP10 testing. 

What version were you running in #c15?

Comment 17 Paul Grist 2016-10-14 01:23:45 UTC

This is a bug it would be good to fix sooner than later. Adding some people that could possibly check it during other OSP10 testing. 

What version were you running in #c15?

Comment 18 Paul Grist 2016-10-15 14:28:49 UTC

Do we know if this is still an issue in OSP10/Newton?

Comment 20 Tzach Shefi 2016-11-30 15:07:09 UTC

Paul, looks like this doesn't happen any more. 

On a RHOS10 build date: 2016-11-22.3
Added a #comment on cinder.conf on all 3 controllers
Reran deployment command, comment on cinder.conf remains post redeploy.

Comment 21 Sean Cohen 2016-12-07 14:25:28 UTC

(In reply to Tzach Shefi from comment #20)
> Paul, looks like this doesn't happen any more. 
> 
> On a RHOS10 build date: 2016-11-22.3
> Added a #comment on cinder.conf on all 3 controllers
> Reran deployment command, comment on cinder.conf remains post redeploy.

Thanks Tzach,
Closing current release accordingly.
Sean