Chapter 3. Parameters
Each Heat template in the director’s template collection contains a parameters
section. This section defines all parameters specific to a particular overcloud service. This includes the following:
-
overcloud.j2.yaml
- Default base parameters -
roles_data.yaml
- Default parameters for composable roles -
puppet/services/*.yaml
- Default parameters for specific services
You can modify the values for these parameters using the following method:
- Create an environment file for your custom parameters.
-
Include your custom parameters in the
parameter_defaults
section of the environment file. -
Include the environment file with the
openstack overcloud deploy
command.
The next few sections contain examples to demonstrate how to configure specific parameters for services in the puppet/services
directory.
3.1. Example 1: Configuring the Timezone
The Heat template for setting the timezone (puppet/services/time/timezone.yaml
) contains a TimeZone
parameter. If you leave the TimeZone
parameter blank, the overcloud sets the time to UTC
as a default.
To obtain lists of timezones run the timedatectl list-timezones
command. The following example command retrieves the timezones for Asia:
$ sudo timedatectl list-timezones|grep "Asia"
After you identify your timezone, set the TimeZone parameter in an environment file. The following example environment file sets the value of TimeZone to Asia/Tokyo:
parameter_defaults: TimeZone: 'Asia/Tokyo'
3.2. Example 2: Enabling Networking Distributed Virtual Routing (DVR)
The Heat template for the OpenStack Networking (neutron) API (puppet/services/neutron-api.yaml
) contains a parameter to enable and disable Distributed Virtual Routing (DVR). The default for the parameter is false
. However, you can enable it using the following in an environment file:
parameter_defaults: NeutronEnableDVR: true
3.3. Example 3: Configuring RabbitMQ File Descriptor Limit
For certain configurations, you might need to increase the file descriptor limit for the RabbitMQ server. The puppet/services/rabbitmq.yaml
Heat template allows you to set the RabbitFDLimit
parameter to the limit you require. Add the following to an environment file.
parameter_defaults: RabbitFDLimit: 65536
3.4. Example 4: Enabling and Disabling Parameters
In some case, you might need to initially set a parameters during a deployment, then disable the parameter for a future deployment operation, such as updates or scaling operations. For example, to include a custom RPM during the overcloud creation, you would include the following:
parameter_defaults: DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]
If you need to disable this parameter from a future deployment, it is not enough to remove the parameter. Instead, you set the parameter to an empty value:
parameter_defaults: DeployArtifactURLs: []
This ensures the parameter is no longer set for subsequent deployments operations.
3.5. Example 5: Role-based parameters
Use the [ROLE]Parameters
parameters, replacing [ROLE]
with a composable role, to set parameters for a specific role.
For example, director configures logrotate
on both Controller and Compute nodes. To set a different different logrotate
parameters for Controller and Compute nodes, create an environment file that contains both the ‘ControllerParameters’ and ‘ComputeParameters’ parameter and set the logrotate parameter for each specific role:
parameter_defaults: ControllerParameters: LogrotateMaxsize: 10M LogrotatePurgeAfterDays: 30 ComputeParameters: LogrotateMaxsize: 20M LogrotatePurgeAfterDays: 15
3.6. Identifying Parameters to Modify
Red Hat OpenStack Platform director provides many parameters for configuration. In some cases, you might experience difficulty identifying a certain option to configure and the corresponding director parameter. If there is an option you want to configure through the director, use the following workflow to identify and map the option to a specific overcloud parameter:
- Identify the option you aim to configure. Make a note of the service that uses the option.
Check the corresponding Puppet module for this option. The Puppet modules for Red Hat OpenStack Platform are located under
/etc/puppet/modules
on the director node. Each module corresponds to a particular service. For example, thekeystone
module corresponds to the OpenStack Identity (keystone).- If the Puppet module contains a variable that controls the chosen option, move to the next step.
- If the Puppet module does not contain a variable that controls the chosen option, then no hieradata exists for this option. If possible, you can set the option manually after the overcloud completes deployment.
Check the director’s core Heat template collection for the Puppet variable in the form of hieradata. The templates in
puppet/services/*
usually correspond to the Puppet modules of the same services. For example, thepuppet/services/keystone.yaml
template provides hieradata to thekeystone
module.- If the Heat template sets hieradata for the Puppet variable, the template should also disclose the director-based parameter to modify.
- If the Heat template does not set hieradata for the Puppet variable, use the configuration hooks to pass the hieradata using an environment file. See Section 4.5, “Puppet: Customizing Hieradata for Roles” for more information on customizing hieradata.
Do not define multiple instances of the same custom hieradata hashes. Multiple instances of the same custom hieradata can cause conflicts during Puppet runs and result in unexpected values set for configuration options.
Workflow Example
You might aim to change the notification format for OpenStack Identity (keystone). Using the workflow, you would:
-
Identify the OpenStack parameter to configure (
notification_format
). Search the
keystone
Puppet module for thenotification_format
setting. For example:$ grep notification_format /etc/puppet/modules/keystone/manifests/*
In this case, the
keystone
module manages this option using thekeystone::notification_format
variable.Search the
keystone
service template for this variable. For example:$ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/puppet/services/keystone.yaml
The output shows the director using the
KeystoneNotificationFormat
parameter to set thekeystone::notification_format
hieradata.
The following table shows the eventual mapping:
Director Parameter | Puppet Hieradata | OpenStack Identity (keystone) option |
---|---|---|
|
|
|
This means setting the KeystoneNotificationFormat
in an overcloud’s environment file would set the notification_format
option in the keystone.conf
file during the overcloud’s configuration.