Advanced Overcloud Customization

1. Loads the default configuration from the core heat template collection.
2. Applies the configuration from environment-file-1.yaml, which overrides any common settings from the default configuration.
3. Applies the configuration from environment-file-2.yaml, which overrides any common settings from the default configuration and environment-file-1.yaml.

1. Identify the option that you want to configure. Make a note of the service that uses the option.

2. 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, the keystone 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, no hieradata exists for this option. If possible, you can set the option manually after the overcloud completes deployment.

3. Check the core heat template collection for the Puppet variable in the form of hieradata. The templates in deployment/* usually correspond to the Puppet modules of the same services. For example, the deployment/keystone/keystone-container-puppet.yaml template provides hieradata to the keystone module.

   • If the heat template sets hieradata for the Puppet variable, the template should also disclose the director-based parameter that you can 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.

Procedure

1. To change the notification format for OpenStack Identity (keystone), use the workflow and complete the following steps:

   1. Identify the OpenStack parameter that you want to configure (notification_format).

   2. Search the keystone Puppet module for the notification_format setting:

      $ grep notification_format /etc/puppet/modules/keystone/manifests/*

      Copy to Clipboard Toggle word wrap

      In this case, the keystone module manages this option using the keystone::notification_format variable.

   3. Search the keystone service template for this variable:

      $ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml

      Copy to Clipboard Toggle word wrap

      The output shows that director uses the KeystoneNotificationFormat parameter to set the keystone::notification_format hieradata.

Procedure

1. Create a basic heat template ~/templates/nameserver.yaml that runs a script to append the resolv.conf file on each node with a specific nameserver. You can use the OS::TripleO::MultipartMime resource type to send the configuration script.

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   resources:
     userdata:
       type: OS::Heat::MultipartMime
       properties:
         parts:
         - config: {get_resource: nameserver_config}
   
     nameserver_config:
       type: OS::Heat::SoftwareConfig
       properties:
         config: |
           #!/bin/bash
           echo "nameserver 192.168.1.1" >> /etc/resolv.conf
   
   outputs:
     OS::stack_id:
       value: {get_resource: userdata}

   Copy to Clipboard Toggle word wrap

2. Create an environment file ~/templates/firstboot.yaml that registers your heat template as the OS::TripleO::NodeUserData resource type.

   resource_registry:
     OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml

   Copy to Clipboard Toggle word wrap

3. To add the first boot configuration to your overcloud, add the environment file to the stack, along with your other environment files:

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/firstboot.yaml \
       ...

   Copy to Clipboard Toggle word wrap

   This adds the configuration to all nodes when they are first created and boot for the first time. Subsequent inclusion of these templates, such as updating the overcloud stack, does not run these scripts.

Procedure

1. Create a basic heat template ~/templates/nameserver.yaml that runs a script to write a variable nameserver to the resolv.conf file of a node:

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   parameters:
     server:
       type: string
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
   
   resources:
     CustomExtraConfigPre:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template: |
               #!/bin/sh
               echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
             params:
               _NAMESERVER_IP_: {get_param: nameserver_ip}
   
     CustomExtraDeploymentPre:
       type: OS::Heat::SoftwareDeployment
       properties:
         server: {get_param: server}
         config: {get_resource: CustomExtraConfigPre}
         actions: ['CREATE','UPDATE']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}
   
   outputs:
     deploy_stdout:
       description: Deployment reference, used to trigger pre-deploy on changes
       value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

   Copy to Clipboard Toggle word wrap

   In this example, the resources section contains the following parameters:

   CustomExtraConfigPre

   This defines a software configuration. In this example, we define a Bash script and heat replaces _NAMESERVER_IP_ with the value stored in the nameserver_ip parameter.

   CustomExtraDeploymentPre

   This executes a software configuration, which is the software configuration from the CustomExtraConfigPre resource. Note the following:

   • The config parameter references the CustomExtraConfigPre resource so that heat knows which configuration to apply.
   • The server parameter retrieves a map of the overcloud nodes. This parameter is provided by the parent template and is mandatory in templates for this hook.
   • The actions parameter defines when to apply the configuration. Possible actions include CREATE and UPDATE, which are both set by default. In this case, you only apply the configuration when the overcloud is created.
   • input_values contains a parameter called deploy_identifier, which stores the DeployIdentifier from the parent template. This parameter provides a timestamp to the resource for each deployment update to ensure that the resource reapplies on subsequent overcloud updates.

2. Create an environment file ~/templates/pre_config.yaml that registers your heat template to the role-based resource type. For example, to apply the configuration only to Controller nodes, use the ControllerExtraConfigPre hook:

   resource_registry:
     OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
   
   parameter_defaults:
     nameserver_ip: 192.168.1.1

   Copy to Clipboard Toggle word wrap

3. Add the environment file to the stack, along with your other environment files:

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/pre_config.yaml \
       ...

   Copy to Clipboard Toggle word wrap

   This applies the configuration to all Controller nodes before the core configuration begins on either the initial overcloud creation or subsequent updates.

Procedure

1. Create a basic heat template ~/templates/nameserver.yaml that runs a script to append the resolv.conf file of each node with a variable nameserver:

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   parameters:
     server:
       type: string
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
   
   resources:
     CustomExtraConfigPre:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template: |
               #!/bin/sh
               echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
             params:
               _NAMESERVER_IP_: {get_param: nameserver_ip}
   
     CustomExtraDeploymentPre:
       type: OS::Heat::SoftwareDeployment
       properties:
         server: {get_param: server}
         config: {get_resource: CustomExtraConfigPre}
         actions: ['CREATE','UPDATE']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}
   
   outputs:
     deploy_stdout:
       description: Deployment reference, used to trigger pre-deploy on changes
       value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

   Copy to Clipboard Toggle word wrap

   In this example, the resources section contains the following parameters:

   CustomExtraConfigPre

   This parameter defines a software configuration. In this example, you define a Bash script and heat replaces _NAMESERVER_IP_ with the value stored in the nameserver_ip parameter.

   CustomExtraDeploymentPre

   This parameter executes a software configuration, which is the software configuration from the CustomExtraConfigPre resource. Note the following:

   • The config parameter references the CustomExtraConfigPre resource so that heat knows which configuration to apply.
   • The server parameter retrieves a map of the overcloud nodes. This parameter is provided by the parent template and is mandatory in templates for this hook.
   • The actions parameter defines when to apply the configuration. Possible actions include CREATE and UPDATE, which are both set by default. In this case, you only apply the configuration when the overcloud is created.
   • The input_values parameter contains a sub-parameter called deploy_identifier, which stores the DeployIdentifier from the parent template. This parameter provides a timestamp to the resource for each deployment update to ensure that the resource reapplies on subsequent overcloud updates.

2. Create an environment file ~/templates/pre_config.yaml that registers your heat template as the OS::TripleO::NodeExtraConfig resource type.

   resource_registry:
     OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
   
   parameter_defaults:
     nameserver_ip: 192.168.1.1

   Copy to Clipboard Toggle word wrap

3. Add the environment file to the stack, along with your other environment files:

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/pre_config.yaml \
       ...

   Copy to Clipboard Toggle word wrap

   This applies the configuration to all nodes before the core configuration begins on either the initial overcloud creation or subsequent updates.

Procedure

1. Create a basic heat template ~/templates/nameserver.yaml that runs a script to append the resolv.conf file of each node with a variable nameserver:

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   parameters:
     servers:
       type: json
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
     EndpointMap:
       default: {}
       type: json
   
   resources:
     CustomExtraConfig:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template: |
               #!/bin/sh
               echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
             params:
               _NAMESERVER_IP_: {get_param: nameserver_ip}
   
     CustomExtraDeployments:
       type: OS::Heat::SoftwareDeploymentGroup
       properties:
         servers:  {get_param: servers}
         config: {get_resource: CustomExtraConfig}
         actions: ['CREATE','UPDATE']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}

   Copy to Clipboard Toggle word wrap

   In this example, the resources section contains the following parameters:

   CustomExtraConfig

   This defines a software configuration. In this example, you define a Bash script and heat replaces _NAMESERVER_IP_ with the value stored in the nameserver_ip parameter.

   CustomExtraDeployments

   This executes a software configuration, which is the software configuration from the CustomExtraConfig resource. Note the following:

   • The config parameter references the CustomExtraConfig resource so that heat knows which configuration to apply.
   • The servers parameter retrieves a map of the overcloud nodes. This parameter is provided by the parent template and is mandatory in templates for this hook.
   • The actions parameter defines when to apply the configuration. Possible actions include CREATE and UPDATE, which are both set by default. In this case, you only apply the configuration when the overcloud is created.
   • input_values contains a parameter called deploy_identifier, which stores the DeployIdentifier from the parent template. This parameter provides a timestamp to the resource for each deployment update to ensure that the resource reapplies on subsequent overcloud updates.

2. Create an environment file ~/templates/post_config.yaml that registers your heat template as the OS::TripleO::NodeExtraConfigPost: resource type.

   resource_registry:
     OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
   
   parameter_defaults:
     nameserver_ip: 192.168.1.1

   Copy to Clipboard Toggle word wrap

3. Add the environment file to the stack, along with your other environment files:

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/post_config.yaml \
       ...

   Copy to Clipboard Toggle word wrap

   This applies the configuration to all nodes after the core configuration completes on either initial overcloud creation or subsequent updates.

Procedure

1. To add extra configuration to the post-deployment configuration process, create an environment file that contains these parameters in the parameter_defaults section. For example, to increase the reserved memory for Compute hosts to 1024 MB and set the VNC keymap to Japanese, use the following entries in the ComputeExtraConfig parameter:

   parameter_defaults:
     ComputeExtraConfig:
       nova::compute::reserved_host_memory: 1024
       nova::compute::vnc_keymap: ja

   Copy to Clipboard Toggle word wrap
2. Include this environment file in the openstack overcloud deploy command, along with any other environment files relevant to your deployment.

Procedure

1. Identify the system UUID from the introspection data for a node:

   $ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

   Copy to Clipboard Toggle word wrap

   This command returns a system UUID. For example:

   "f5055c6c-477f-47fb-afe5-95c6928c407f"

   Copy to Clipboard Toggle word wrap

2. Create an environment file to define node-specific hieradata and register the per_node.yaml template to a pre-configuration hook. Include the system UUID of the node that you want to configure in the NodeDataLookup parameter:

   resource_registry:
     OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
   parameter_defaults:
     NodeDataLookup: '{"f5055c6c-477f-47fb-afe5-95c6928c407f": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'

   Copy to Clipboard Toggle word wrap
3. Include this environment file in the openstack overcloud deploy command, along with any other environment files relevant to your deployment.

Procedure

1. Create a heat template ~/templates/custom_puppet_config.yaml that launches Puppet configuration.

   heat_template_version: 2014-10-16
   
   description: >
     Run Puppet extra configuration to set new MOTD
   
   parameters:
     servers:
       type: json
     DeployIdentifier:
       type: string
     EndpointMap:
       default: {}
       type: json
   
   resources:
     ExtraPuppetConfig:
       type: OS::Heat::SoftwareConfig
       properties:
         config: {get_file: motd.pp}
         group: puppet
         options:
           enable_hiera: True
           enable_facter: False
   
     ExtraPuppetDeployments:
       type: OS::Heat::SoftwareDeploymentGroup
       properties:
         config: {get_resource: ExtraPuppetConfig}
         servers: {get_param: servers}

   Copy to Clipboard Toggle word wrap

   This example includes the /home/stack/templates/motd.pp within the template and passes it to nodes for configuration. The motd.pp file contains the Puppet classes necessary to install and configure motd.

2. Create an environment file ~templates/puppet_post_config.yaml that registers your heat template as the OS::TripleO::NodeExtraConfigPost: resource type.

   resource_registry:
     OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml

   Copy to Clipboard Toggle word wrap

3. Include this environment file in the openstack overcloud deploy command, along with any other environment files relevant to your deployment.

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/puppet_post_config.yaml \
       ...

   Copy to Clipboard Toggle word wrap

   This applies the configuration from motd.pp to all nodes in the overcloud.

Procedure

1. Create an environment file named templates/rhsm.yml to store the configuration.

2. Include your configuration in the environment file. For example:

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         …​
       rhsm_username: "myusername"
       rhsm_password: "p@55w0rd!"
       rhsm_org_id: "1234567"
       rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
       rhsm_method: "portal"
       rhsm_release: 8.4

   Copy to Clipboard Toggle word wrap
   • The resource_registry section associates the rhsm composable service with the OS::TripleO::Services::Rhsm resource, which is available on each role.
   • The RhsmVars variable passes parameters to Ansible for configuring your Red Hat registration.
3. Save the environment file.

Procedure

1. Create an environment file named templates/rhsm.yml to store the configuration.

2. Include your configuration in the environment file. For example:

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     ControllerParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     ComputeParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     CephStorageParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-rpms
           - rhel-8-for-x86_64-appstream-rpms
           - rhel-8-for-x86_64-highavailability-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
         rhsm_method: "portal"
         rhsm_release: 8.4

   Copy to Clipboard Toggle word wrap

   The resource_registry associates the rhsm composable service with the OS::TripleO::Services::Rhsm resource, which is available on each role.

   The ControllerParameters, ComputeParameters, and CephStorageParameters parameters each use a separate RhsmVars parameter to pass subscription details to their respective roles.

   Note

   Set the RhsmVars parameter within the CephStorageParameters parameter to use a Red Hat Ceph Storage subscription and repositories specific to Ceph Storage. Ensure the rhsm_repos parameter contains the standard Red Hat Enterprise Linux repositories instead of the Extended Update Support (EUS) repositories that Controller and Compute nodes require.

3. Save the environment file.

Procedure

1. Create an environment file named templates/rhsm.yml to store the configuration.

2. Include your configuration in the environment file. For example:

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_activation_key: "myactivationkey"
       rhsm_method: "satellite"
       rhsm_org_id: "ACME"
       rhsm_server_hostname: "satellite.example.com"
       rhsm_baseurl: "https://satellite.example.com/pulp/repos"
       rhsm_release: 8.4

   Copy to Clipboard Toggle word wrap

   The resource_registry associates the rhsm composable service with the OS::TripleO::Services::Rhsm resource, which is available on each role.

   The RhsmVars variable passes parameters to Ansible for configuring your Red Hat registration.

3. Save the environment file.

Procedure

1. Exclude the rhel-registration environment files from future deployments operations. In most cases, exclude the following files:

   • rhel-registration/environment-rhel-registration.yaml
   • rhel-registration/rhel-registration-resource-registry.yaml

2. If you use a custom roles_data file, ensure that each role in your roles_data file contains the OS::TripleO::Services::Rhsm composable service. For example:

   - name: Controller
     description: |
       Controller role that has all the controller services loaded and handles
       Database, Messaging and Network functions.
     CountDefault: 1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Rhsm
       ...

   Copy to Clipboard Toggle word wrap
3. Add the environment file for rhsm composable service parameters to future deployment operations.

Procedure

1. Include rhsm.yml environment file with the openstack overcloud deploy command:

   openstack overcloud deploy \
       <other cli args> \
       -e ~/templates/rhsm.yaml

   Copy to Clipboard Toggle word wrap

   This enables the Ansible configuration of the overcloud and the Ansible-based registration.

2. Wait until the overcloud deployment completes.

3. Check the subscription details on your overcloud nodes. For example, log in to a Controller node and run the following commands:

   $ sudo subscription-manager status
   $ sudo subscription-manager list --consumed

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook that uses the redhat_subscription modules to register your nodes. For example, the following playbook applies to Controller nodes:

   ---
   - name: Register Controller nodes
     hosts: Controller
     become: yes
     vars:
       repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         - ansible-2.9-for-rhel-8-x86_64-rpms
         - openstack-beta-for-rhel-8-x86_64-rpms
         - fast-datapath-for-rhel-8-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 8.4
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   Copy to Clipboard Toggle word wrap

   • This play contains three tasks:

     • Register the node.
     • Disable any auto-enabled repositories.
     • Enable only the repositories relevant to the Controller node. The repositories are listed with the repos variable.

2. After you deploy the overcloud, you can run the following command so that Ansible executes the playbook (ansible-osp-registration.yml) against your overcloud:

   $ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml

   Copy to Clipboard Toggle word wrap

   This command performs the following actions:

   • Runs the dynamic inventory script to get a list of host and their groups.
   • Applies the playbook tasks to the nodes in the group defined in the hosts parameter of the playbook, which in this case is the Controller group.

Procedure

1. List the default role templates:

   $ openstack overcloud roles list
   BlockStorage
   CephStorage
   Compute
   ComputeHCI
   ComputeOvsDpdk
   Controller
   ...

   Copy to Clipboard Toggle word wrap

2. View the role definition in YAML format with the openstack overcloud roles show command:

   $ openstack overcloud roles show Compute

   Copy to Clipboard Toggle word wrap

3. Generate a custom roles_data file. Use the openstack overcloud roles generate command to join multiple predefined roles into a single file. For example, run the following command to generate a roles_data.yaml file that contains the Controller, Compute, and Networker roles:

   $ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker

   Copy to Clipboard Toggle word wrap

   Use the -o option to define the name out of the output file.

   This command creates a custom roles_data file. However, the previous example uses the Controller and Networker roles, which both contain the same networking agents. This means that the networking services scale from the Controller role to the Networker role and the overcloud balances the load for networking services between the Controller and Networker nodes.

   To make this Networker role standalone, you can create your own custom Controller role, as well as any other role that you require. This allows you to generate a roles_data file from your own custom roles.

4. Copy the directory from the core heat template collection to the home directory of the stack user:

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

   Copy to Clipboard Toggle word wrap

5. Add or modify the custom role files in this directory. Use the --roles-path option with any of the role sub-commands to use this directory as the source for your custom roles:

   $ openstack overcloud roles generate -o my_roles_data.yaml \
     --roles-path ~/roles \
     Controller Compute Networker

   Copy to Clipboard Toggle word wrap

   This command generates a single my_roles_data.yaml file from the individual roles in the ~/roles directory.

Procedure

1. Create a custom copy of the default roles directory:

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

   Copy to Clipboard Toggle word wrap

2. Create a new file called ~/roles/Horizon.yaml and create a new Horizon role that contains base and core OpenStack Dashboard services:

   - name: Horizon
     CountDefault: 1
     HostnameFormatDefault: '%stackname%-horizon-%index%'
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Sshd
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::MySQLClient
       - OS::TripleO::Services::Apache
       - OS::TripleO::Services::Horizon

   Copy to Clipboard Toggle word wrap
   • Set the name parameter to the name of the custom role. Custom role names have a maximum length of 47 characters.
   • Set the CountDefault parameter to 1 so that a default overcloud always includes the Horizon node.

3. Optional: If you want to scale the services in an existing overcloud, retain the existing services on the Controller role. If you want to create a new overcloud and you want the OpenStack Dashboard to remain on the standalone role, remove the OpenStack Dashboard components from the Controller role definition:

   - name: Controller
     CountDefault: 1
     ServicesDefault:
       ...
       - OS::TripleO::Services::GnocchiMetricd
       - OS::TripleO::Services::GnocchiStatsd
       - OS::TripleO::Services::HAproxy
       - OS::TripleO::Services::HeatApi
       - OS::TripleO::Services::HeatApiCfn
       - OS::TripleO::Services::HeatApiCloudwatch
       - OS::TripleO::Services::HeatEngine
       # - OS::TripleO::Services::Horizon                # Remove this service
       - OS::TripleO::Services::IronicApi
       - OS::TripleO::Services::IronicConductor
       - OS::TripleO::Services::Iscsid
       - OS::TripleO::Services::Keepalived
       ...

   Copy to Clipboard Toggle word wrap

4. Generate the new roles_data-horizon.yaml file using the ~/roles directory as the source:

   $ openstack overcloud roles generate -o roles_data-horizon.yaml \
     --roles-path ~/roles \
     Controller Compute Horizon

   Copy to Clipboard Toggle word wrap

5. Define a new flavor for this role so that you can tag specific nodes. For this example, use the following commands to create a horizon flavor:

   1. Create a horizon flavor:

      (undercloud)$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon

      Copy to Clipboard Toggle word wrap
      Note

      These properties are not used for scheduling instances, however, the Compute scheduler does use the disk size to determine the root partition size.

   2. Tag each bare metal node that you want to designate for the Dashboard service (horizon) with a custom resource class:

      (undercloud)$ openstack baremetal node set --resource-class baremetal.HORIZON <NODE>

      Copy to Clipboard Toggle word wrap

      Replace <NODE> with the ID of the bare metal node.

   3. Associate the horizon flavor with the custom resource class:

      (undercloud)$ openstack flavor set --property resources:CUSTOM_BAREMETAL_HORIZON=1 horizon

      Copy to Clipboard Toggle word wrap

      To determine the name of a custom resource class that corresponds to a resource class of a bare metal node, convert the resource class to uppercase, replace punctuation with an underscore, and prefix the value with CUSTOM_.

      Note

      A flavor can request only one instance of a bare metal resource class.

   4. Set the following flavor properties to prevent the Compute scheduler from using the bare metal flavor properties for scheduling instances:

      (undercloud)$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 horizon

      Copy to Clipboard Toggle word wrap

6. Define the Horizon node count and flavor using the following environment file snippet:

   parameter_defaults:
     OvercloudHorizonFlavor: horizon
     HorizonCount: 1

   Copy to Clipboard Toggle word wrap

7. Include the new roles_data-horizon.yaml file and environment file in the openstack overcloud deploy command, along with any other environment files relevant to your deployment:

   $ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml

   Copy to Clipboard Toggle word wrap

   This configuration creates a three-node overcloud that consists of one Controller node, one Compute node, and one Networker node. To view the list of nodes in your overcloud, run the following command:

   $ openstack server list

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a custom copy of the default roles directory:

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

   Copy to Clipboard Toggle word wrap

2. Edit the ~/roles/Controller.yaml file and modify the service list for the ServicesDefault parameter. Scroll to the OpenStack Orchestration services and remove them:

       - OS::TripleO::Services::GlanceApi
       - OS::TripleO::Services::GlanceRegistry
       - OS::TripleO::Services::HeatApi            # Remove this service
       - OS::TripleO::Services::HeatApiCfn         # Remove this service
       - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
       - OS::TripleO::Services::HeatEngine         # Remove this service
       - OS::TripleO::Services::MySQL
       - OS::TripleO::Services::NeutronDhcpAgent

   Copy to Clipboard Toggle word wrap

3. Generate the new roles_data file:

   $ openstack overcloud roles generate -o roles_data-no_heat.yaml \
     --roles-path ~/roles \
     Controller Compute Networker

   Copy to Clipboard Toggle word wrap

4. Include this new roles_data file when you run the openstack overcloud deploy command:

   $ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

   Copy to Clipboard Toggle word wrap

   This command deploys an overcloud without OpenStack Orchestration services installed on the Controller nodes.

Procedure

1. Add an entry in an environment file that links the CinderBackup service to the heat template that contains the cinder-backup configuration:

   resource_registry:
     OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml
   ...

   Copy to Clipboard Toggle word wrap

   This entry overrides the default null operation resource and enables the service.

2. Include this environment file when you run the openstack overcloud deploy command:

   $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a generic role in your custom roles_data.yaml file that does not contain a ServicesDefault list:

   - name: Generic
   - name: Controller
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephClient
       ...
   - name: Compute
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephClient
       ...

   Copy to Clipboard Toggle word wrap

   Ensure that you retain the existing Controller and Compute roles.

2. Create an environment file generic-node-params.yaml to specify how many generic Red Hat Enterprise Linux 8 nodes you require and the flavor when selecting nodes to provision:

   parameter_defaults:
     OvercloudGenericFlavor: baremetal
     GenericCount: 1

   Copy to Clipboard Toggle word wrap

3. Include both the roles file and the environment file when you run the openstack overcloud deploy command:

   $ openstack overcloud deploy --templates \
   -r ~/templates/roles_data_with_generic.yaml \
   -e ~/templates/generic-node-params.yaml

   Copy to Clipboard Toggle word wrap

   This configuration deploys a three-node environment with one Controller node, one Compute node, and one generic Red Hat Enterprise Linux 8 node.

Procedure

1. Log in to your undercloud host as the stack user.

2. Generate the default container image preparation file:

   $ sudo openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

   Copy to Clipboard Toggle word wrap

   This command includes the following additional options:

   • --local-push-destination sets the registry on the undercloud as the location for container images. This means that director pulls the necessary images from the Red Hat Container Catalog and pushes them to the registry on the undercloud. Director uses this registry as the container image source. To pull directly from the Red Hat Container Catalog, omit this option.

   • --output-env-file is an environment file name. The contents of this file include the parameters for preparing your container images. In this case, the name of the file is containers-prepare-parameter.yaml.

     Note

     You can use the same containers-prepare-parameter.yaml file to define a container image source for both the undercloud and the overcloud.

3. Modify the containers-prepare-parameter.yaml to suit your requirements.

Procedure

1. The following example runs the custom Dockerfile on the nova-compute image:

   ContainerImagePrepare:
   - push_destination: true
     ...
     includes:
     - nova-compute
     modify_role: tripleo-modify-image
     modify_append_tag: "-hotfix"
     modify_vars:
       tasks_from: modify_image.yml
       modify_dir_path: /home/stack/nova-custom
     ...

   Copy to Clipboard Toggle word wrap

2. The following example shows the /home/stack/nova-custom/Dockerfile file. After you run any USER root directives, you must switch back to the original image default user:

   FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest
   
   USER "root"
   
   COPY customize.sh /tmp/
   RUN /tmp/customize.sh
   
   USER "nova"

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a new container images file for your overcloud:

   $ sudo openstack tripleo container image prepare default \
       --local-push-destination \
       --output-env-file containers-prepare-parameter-dellemc.yaml

   Copy to Clipboard Toggle word wrap
2. Edit the containers-prepare-parameter-dellemc.yaml file.

3. Add an exclude parameter to the strategy for the main Red Hat OpenStack Platform container images. Use this parameter to exclude the container image that the vendor container image will replace. In the example, the container image is the cinder-volume image:

   parameter_defaults:
     ContainerImagePrepare:
       - push_destination: true
         excludes:
     	   - cinder-volume
         set:
           namespace: registry.redhat.io/rhosp-rhel8
           name_prefix: openstack-
           name_suffix: ''
           tag: 16.2
           ...
         tag_from_label: "{version}-{release}"

   Copy to Clipboard Toggle word wrap

4. Add a new strategy to the ContainerImagePrepare parameter that includes the replacement container image for the vendor plugin:

   parameter_defaults:
     ContainerImagePrepare:
       ...
       - push_destination: true
         includes:
           - cinder-volume
         set:
           namespace: registry.connect.redhat.com/dellemc
           name_prefix: openstack-
           name_suffix: -dellemc-rhosp16
           tag: 16.2-2
           ...

   Copy to Clipboard Toggle word wrap

5. Add the authentication details for the registry.connect.redhat.com registry to the ContainerImageRegistryCredentials parameter:

   parameter_defaults:
     ContainerImageRegistryCredentials:
       registry.redhat.io:
         [service account username]: [service account password]
       registry.connect.redhat.com:
         [service account username]: [service account password]

   Copy to Clipboard Toggle word wrap
6. Save the containers-prepare-parameter-dellemc.yaml file.

7. Include the containers-prepare-parameter-dellemc.yaml file with any deployment commands, such as as openstack overcloud deploy:

   $ openstack overcloud deploy --templates
       ...
       -e containers-prepare-parameter-dellemc.yaml
       ...

   Copy to Clipboard Toggle word wrap

   When director deploys the overcloud, the overcloud uses the vendor container image instead of the standard container image.

   IMPORTANT

   The containers-prepare-parameter-dellemc.yaml file replaces the standard containers-prepare-parameter.yaml file in your overcloud deployment. Do not include the standard containers-prepare-parameter.yaml file in your overcloud deployment. Retain the standard containers-prepare-parameter.yaml file for your undercloud installation and updates.

Procedure

1. Copy the default network_data.yaml file:

   $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.

   Copy to Clipboard Toggle word wrap

2. Edit the local copy of the network_data.yaml file and modify the parameters to suit your networking requirements. For example, the Internal API network contains the following default network details:

   - name: InternalApi
     name_lower: internal_api
     vip: true
     vlan: 201
     ip_subnet: '172.16.2.0/24'
     allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]

   Copy to Clipboard Toggle word wrap

Procedure

1. When you run the openstack overcloud deploy command, ensure that you include the following rendered environment files:

   • The custom network_data.yaml file.
   • The rendered file name of the default network isolation file.
   • The rendered file name of the default network environment file.
   • The rendered file name of the default network interface configuration file.
   • Any additional environment files relevant to your configuration.

Procedure

1. Copy the default network_data.yaml file:

   $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.

   Copy to Clipboard Toggle word wrap

2. Edit the local copy of the network_data.yaml file and add a section for your new network:

   - name: StorageBackup
     name_lower: storage_backup
     vlan: 21
     vip: true
     ip_subnet: '172.21.1.0/24'
     allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
     gateway_ip: '172.21.1.1'

   Copy to Clipboard Toggle word wrap

   You can use the following parameters in your network_data.yaml file:

   name

   Sets the human readable name of the network. This parameter is the only mandatory parameter. You can also use name_lower to normalize names for readability. For example, change InternalApi to internal_api.

   name_lower

   Sets the lowercase version of the name, which director maps to respective networks assigned to roles in the roles_data.yaml file.

   vlan

   Sets the VLAN that you want to use for this network.

   vip: true

   Creates a virtual IP address (VIP) on the new network. This IP is used as the target IP for services listed in the service-to-network mapping parameter (ServiceNetMap). Note that VIPs are used only by roles that use Pacemaker. The overcloud load-balancing service redirects traffic from these IPs to their respective service endpoint.

   ip_subnet

   Sets the default IPv4 subnet in CIDR format.

   allocation_pools

   Sets the IP range for the IPv4 subnet

   gateway_ip

   Sets the gateway for the network.

   routes

   Adds additional routes to the network. Uses a JSON list that contains each additional route. Each list item contains a dictionary value mapping. Use the following example syntax:

     routes: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.2.254'}]

   Copy to Clipboard Toggle word wrap

   subnets

   Creates additional routed subnets that fall within this network. This parameter accepts a dict value that contains the lowercase name of the routed subnet as the key and the vlan, ip_subnet, allocation_pools, and gateway_ip parameters as the value mapped to the subnet. The following example demonstrates this layout:

   - name: StorageBackup
     name_lower: storage_backup
     vlan: 200
     vip: true
     ip_subnet: '172.21.0.0/24'
     allocation_pools: [{'start': '171.21.0.4', 'end': '172.21.0.250'}]
     gateway_ip: '172.21.0.1'
     subnets:
       storage_backup_leaf1:
         vlan: 201
         ip_subnet: '172.21.1.0/24'
         allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
         gateway_ip: '172.19.1.254'

   Copy to Clipboard Toggle word wrap

   This mapping is common in spine leaf deployments. For more information, see the Spine Leaf Networking guide.

3. When you add an extra composable network that contains a virtual IP, and want to map some API services to this network, use the CloudName{network.name} definition to set the DNS name for the API endpoint:

   CloudName{{network.name}}

   Copy to Clipboard Toggle word wrap

   Here is an example:

   parameter_defaults:
     ...
     CloudNameOcProvisioning: baremetal-vip.example.com

   Copy to Clipboard Toggle word wrap
4. Include the custom network_data.yaml file in your deployment command using the -n option. Without the -n option, the deployment command uses the default set of networks.

5. If you want a predictable virtual IP address (VIP), add a VirtualFixedIPs parameter for your custom network to the parameter_defaults section of a heat environment file, for example, my_network_vips.yaml:

   <% my_customer_network %>VirtualFixedIPs:  [{'ip_address':'<% ipaddres %>'}]

   Copy to Clipboard Toggle word wrap

   Here is an example:

   parameter_defaults:
     ...
     # Predictable VIPs
     StorageBackuptVirtualFixedIPs:  [{'ip_address':'172.21.1.9'}]

   Copy to Clipboard Toggle word wrap
6. Include the heat environment file, my_network_vips.yaml, in your deployment command by using the -e option.