Bug 1305009 - cinder.conf gets overwritten on controller nodes upon redeploying an existing overcloud
cinder.conf gets overwritten on controller nodes upon redeploying an existing...
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
x86_64 Linux
high Severity high
: ---
: 10.0 (Newton)
Assigned To: Angus Thomas
Shai Revivo
: Triaged, ZStream
: 1305008 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-05 05:08 EST by Anand Nande
Modified: 2016-12-07 09:25 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-07 09:25:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 4 Sadique Puthen 2016-02-05 06:44:03 EST
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 07:51:16 EST
*** Bug 1305008 has been marked as a duplicate of this bug. ***
Comment 13 Mike Burns 2016-04-07 17:07:13 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 16 Paul Grist 2016-10-13 21:23:19 EDT
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-13 21:23:45 EDT
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 10:28:49 EDT
Do we know if this is still an issue in OSP10/Newton?
Comment 20 Tzach Shefi 2016-11-30 10:07:09 EST
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 09:25:28 EST
(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

Note You need to log in before you can comment on or make changes to this bug.