此内容没有您所选择的语言版本。
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_defaultssection of the environment file. -
Include the environment file with the
openstack overcloud deploycommand.
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 time zone 复制链接链接已复制到粘贴板!
The Heat template for setting the time zone (puppet/services/time/timezone.yaml) contains a TimeZone parameter. If you leave the TimeZone parameter blank, the overcloud sets the time zone to UTC by default. The director recognizes the standard time zone names defined in the time zone database /usr/share/zoneinfo/. For example, if you want to set your time zone to Japan, examine the contents of /usr/share/zoneinfo to locate a suitable entry:
ls /usr/share/zoneinfo/
$ ls /usr/share/zoneinfo/
Africa Asia Canada Cuba EST GB GMT-0 HST iso3166.tab Kwajalein MST NZ-CHAT posix right Turkey UTC Zulu
America Atlantic CET EET EST5EDT GB-Eire GMT+0 Iceland Israel Libya MST7MDT Pacific posixrules ROC UCT WET
Antarctica Australia Chile Egypt Etc GMT Greenwich Indian Jamaica MET Navajo Poland PRC ROK Universal W-SU
Arctic Brazil CST6CDT Eire Europe GMT0 Hongkong Iran Japan Mexico NZ Portugal PST8PDT Singapore US zone.tab
The output listed above includes time zone files and directories containing additional time zone files. For example, Japan is an individual time zone file in this result, but Africa is a directory containing additional time zone files:
ls /usr/share/zoneinfo/Africa/
$ ls /usr/share/zoneinfo/Africa/
Abidjan Algiers Bamako Bissau Bujumbura Ceuta Dar_es_Salaam El_Aaiun Harare Kampala Kinshasa Lome Lusaka Maseru Monrovia Niamey Porto-Novo Tripoli
Accra Asmara Bangui Blantyre Cairo Conakry Djibouti Freetown Johannesburg Khartoum Lagos Luanda Malabo Mbabane Nairobi Nouakchott Sao_Tome Tunis
Addis_Ababa Asmera Banjul Brazzaville Casablanca Dakar Douala Gaborone Juba Kigali Libreville Lubumbashi Maputo Mogadishu Ndjamena Ouagadougou Timbuktu Windhoek
Add the entry in an environment file to set your time zone to Japan:
parameter_defaults: TimeZone: 'Japan'
parameter_defaults:
TimeZone: 'Japan'
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. To enable it, use the following in an environment file:
parameter_defaults: NeutronEnableDVR: true
parameter_defaults:
NeutronEnableDVR: true
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
parameter_defaults:
RabbitFDLimit: 65536
3.4. Example 4: Enabling and Disabling Parameters 复制链接链接已复制到粘贴板!
You might need to initially set a parameter 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, include the following:
parameter_defaults: DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]
parameter_defaults:
DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]
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: []
parameter_defaults:
DeployArtifactURLs: []
This ensures the parameter is no longer set for subsequent deployments operations.
3.5. 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/moduleson the director node. Each module corresponds to a particular service. For example, thekeystonemodule 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, 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.yamltemplate provides hieradata to thekeystonemodule.- 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.
Workflow Example
To change the notification format for OpenStack Identity (keystone), use the workflow and complete the following steps:
-
Identify the OpenStack parameter to configure (
notification_format). Search the
keystonePuppet module for thenotification_formatsetting. For example:grep notification_format /etc/puppet/modules/keystone/manifests/*
$ grep notification_format /etc/puppet/modules/keystone/manifests/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow In this case, the
keystonemodule manages this option using thekeystone::notification_formatvariable.Search the
keystoneservice template for this variable. For example:grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/puppet/services/keystone.yaml
$ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/puppet/services/keystone.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow The output shows the director using the
KeystoneNotificationFormatparameter to set thekeystone::notification_formathieradata.
The following table shows the eventual mapping:
| Director Parameter | Puppet Hieradata | OpenStack Identity (keystone) option |
|---|---|---|
|
|
|
|
You set the KeystoneNotificationFormat in an overcloud’s environment file which in turn sets the notification_format option in the keystone.conf file during the overcloud’s configuration.