Description of problem: Currently, we have a bunch of hard-coded parameter values inside the oscplugin: https://github.com/rdo-management/python-rdomanager-oscplugin/blob/master/rdomanager_oscplugin/v1/overcloud_deploy.py#L73 Some, but not all, of these can be overridden by special CLI options, meaning that certain values (e.g "Debug") cannot be overridden without hacking the code, and the code is heavily coupled to the template implementation which is highly likely to prove fragile and inflexible over time IMHO. Version-Release number of selected component (if applicable): python-rdomanager-oscplugin-0.0.8-41.el7ost.noarch How reproducible: Always Steps to Reproduce: 1. openstack overcloud deploy --templates 2. heat stack-show | grep "Debug" - note it's defaulted to "True" 3. Attempt to update the "Debug" parameter to false (you can't AFAICT). Actual results: Parameters should be configurable, but they are not. Expected results: I think the correct path here is to not hard-code anything in the oscplugin - instead we should maintain an environment file containing all the default parameters, which the oscplugin references. Then, this pattern becomes possible: openstack overcloud deploy --templates -e param_overrides.yaml Where param_overrides.yaml looks like: parameters: Debug: False Alternatively, we could add a more generic --parameters option like python-heatclient, but the above seems simpler and achieves basically the same thing. If we document where the parameter defaults yaml file lives it's also very easy for operators to just copy it, hack on the values and save it - this, IMHO, is much easier than creating a CLI command with a large number of CLI switches/options, which will quickly become unweildy, is inconsistent with normal heat usage, and makes any local alterations to the top-level heat template impossible (heat will reject any parameters not defined in the template).
One approach I've got is here: https://review.gerrithub.io/#/c/243608/ Using this approach I'm able to override any parameters by simply using a custom environment file.
We've just hit this when trying to specify ExtraConfig, as this seems to be one of the hard-coded parameters. Regardless of what we specify in an environment file, ExtraConfig would always be '{}'. For our use case, using 'controllerExtraConfig' instead should suffice for now. The related BZ is bug 1258107.
Moving to urgent and blocker for y2. Not being about to turn off debug is filling up disks in the undercloud.
Note the review Dan posted has now moved to https://review.openstack.org/#/c/221750/ after the client repo moved to upstream TripleO. IMO we should land that and include the fix ASAP, as this is a major usability issue.
Some additional information for things seen during Cisco ML2 driver testing: 1) NeutronNetworkVLANRanges is unable to be set in an override environment file (regardless of parameter section, ie. 'parameters' v. 'parameter_defaults') - workaround: use the command-line option —neutron-network-vlan-ranges 2) controllerExtraConfig: - only works when set in 'parameters:' section in an override environment file - setting it in 'parameter_defaults:' doesn't work - Example: In private (override) environment file: parameters: controllerExtraConfig: { "neutron::server::api_workers": 0, "neutron::server::rpc_workers": 1, } 3) ExtraConfig: - doesn't work, regardless of yaml section 4) NeutronMechanismDrivers setting works within override environment files.
Brad, could you look into this please?
*** Bug 1250654 has been marked as a duplicate of this bug. ***
stack@instack:~>>> heat stack-show overcloud | grep "NeutronVniRanges" | | "NeutronVniRanges": "1:1000", stack@instack:~>>> cat param_overrides.yaml parameters: NeutronVniRanges: "1:3000" stack@instack:~>>> openstack overcloud deploy --templates -e param_overrides.yaml stack@instack:~>>> heat stack-show overcloud | grep "NeutronVniRanges" | | "NeutronVniRanges": "1:3000",
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/RHSA-2015:2650