Bug 1319077

Summary: Some parameter values are "locked" after upgrade from OSP 7 to OSP 8
Product: Red Hat OpenStack Reporter: Jiri Stransky <jstransk>
Component: python-tripleoclientAssignee: Jiri Stransky <jstransk>
Status: CLOSED CURRENTRELEASE QA Contact: Shai Revivo <srevivo>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0 (Liberty)CC: hbrock, jslagle, mburns, rhel-osp-director-maint
Target Milestone: ---   
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-20 13:12:27 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:

Description Jiri Stransky 2016-03-18 15:24:07 UTC 
Description of problem:

After upgrade from OSP 7 to OSP 8, there are some parameters which were set in environment files using `parameters` in OSP 7 but are set using `parameter_defaults` in OSP 8 (e.g. storage related parameters like CinderEnableRbdBackend). Those parameters will not use the new `parameter_defaults` values in the environment files passed on the command line, but will continue using to the old `parameters` values used when deploying OSP 7, because `parameters` take priority over `parameter_defaults`.

This is only issue during upgrades, new deployments work as-is.

Workaround is possible -- if discovered that some `parameter_defaults` values are not taken into account because the overcloud stack already had them set via `parameters` in the past, craft a custom environment file that will set the new desired values via `parameters` again, instead of the new implicit way via `parameter_defaults`.
Comment 2 Jiri Stransky 2016-03-18 15:34:43 UTC 
Posted upstream, pending reviews. https://review.openstack.org/#/c/294675/
Comment 3 Mike Burns 2016-04-07 21:14:44 UTC 
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 5 Jiri Stransky 2016-07-20 13:12:27 UTC 
The fix got merged into stable/liberty and released with OSP 8. No doc required because the problem never got into released code.