Open Stack

On 07/27/2016 06:04 AM, Steven Hardy wrote:
> 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
> here:
>
> http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_config.html
>
> First step is to look at the puppet module that manages that configuration,
> in this case I assume it's puppet-keystone:
>
> https://github.com/openstack/puppet-keystone/tree/master/manifests
>
> Some grepping shows that domain_specific_drivers_enabled is configured
> here:
>
> https://github.com/openstack/puppet-keystone/blob/master/manifests/init.pp#L1124..L1155
>
> So working back from those variables, "using_domain_config" and
> "domain_config_directory", you'd create a yaml file that looks like:
>
> parameter_defaults:
>    ControllerExtraConfig:
>      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
> database?
>
> In that case, puppet has a "passthrough" interface you can use (this is the
> same for all openstack puppet modules AFAIK):
>
> https://github.com/openstack/puppet-keystone/blob/master/manifests/config.pp
>
> Environment (referred to as controller_extra.yaml below) file looks like:
>
> parameter_defaults:
>    ControllerExtraConfig:
>      keystone::config::keystone_config:
>        identity/domain_specific_drivers_enabled:
>          value: true
>        identity/domain_configurations_from_database:
>          value: true
I'm assuming I can mix these two approaches, so that, if I need

keystone::using_domain_config: true



as well it would look like this:

parameter_defaults:
   ControllerExtraConfig:
     keystone::using_domain_config: true
     keystone::config::keystone_config:
       identity/domain_specific_drivers_enabled:
         value: true
       identity/domain_configurations_from_database:
         value: true


And over time,  if there is support put into the templates for the 
values, and we start seeing errors, we can just change from the latter  
approach to the one you posted earlier?
> 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
> requirement.
>
> This is probably something we should add to our docs, I'll look at doing
> that.
>
> Hope that helps,
>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev