[openstack-dev] [tripleo] Modifying just a few values on overcloud redeploy

Steven Hardy shardy at redhat.com
Wed Jul 27 10:04:44 UTC 2016

On Tue, Jul 26, 2016 at 05:23:21PM -0400, Adam Young wrote:
>    I worked through how to do a complete clone of the templates to do a
>    deploy and change a couple values here:
>    http://adam.younglogic.com/2016/06/custom-overcloud-deploys/
>    However, all I want to do is to set two config options in Keystone.  Is
>    there a simple way to just modify the two values below?  Ideally, just
>    making a single env file and passing it via openstack overcloud deploy -e
>    somehow.
>    'identity/domain_specific_drivers_enabled': value => 'True';
>    'identity/domain_configurations_from_database': value => 'True';

Yes, the best way to do this is to pass a hieradata override, as documented


First step is to look at the puppet module that manages that configuration,
in this case I assume it's puppet-keystone:


Some grepping shows that domain_specific_drivers_enabled is configured


So working back from those variables, "using_domain_config" and
"domain_config_directory", you'd create a yaml file that looks like:

    keystone::using_domain_config: true
    keystone::domain_config_directory: /path/to/config

However, it seems that you want to configure domain_specific_drivers_enabled
*without* configuring domain_config_directory, so that it comes from the

In that case, puppet has a "passthrough" interface you can use (this is the
same for all openstack puppet modules AFAIK):


Environment (referred to as controller_extra.yaml below) file looks like:

        value: true
        value: true

Note the somewhat idiosyncratic syntax, you pass the value via a
"value: foo" map, not directly to the configuration key (don't ask me why!)

Then do openstack overcloud deploy --templates /path/to/templates -e controller_extra.yaml

The one gotcha here is if puppet keystone later adds an explicit interface
which conflicts with this, e.g a domain_specific_drivers_enabled variable
in the above referenced init.pp, you will get a duplicate definition error
(because you can't define the same thing twice in the puppet catalog).

This means that long-term use of the generic keystone::config::keystone_config
interface can be fragile, so it's best to add an explicit e.g
keystone::domain_specific_drivers_enabled interface if this is a long-term

This is probably something we should add to our docs, I'll look at doing

Hope that helps,


More information about the OpenStack-dev mailing list