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

Steven Hardy shardy at redhat.com
Wed Jul 27 15:42:10 UTC 2016


On Wed, Jul 27, 2016 at 11:04:22AM -0400, Adam Young wrote:
> 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

Yes, but I think you'll need to remove the
domain_specific_drivers_enabled because that is already set to true via
using_domain_config (see my earlier puppet-keystone link)

So it would look like:

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

As previously mentioned, there appears to be some validation of
keystone::domain_config_directory when you enable
keystone::using_domain_config so you'll probably need to pass both.

> 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?

Yes, this is possible, but it's been a cause of a few CI firedrills, so we
might consider just wiring in the needed interfaces to puppet-keystone now
when you figure out exactly what's required.

Steve



More information about the OpenStack-dev mailing list