Procedure

1. Edit the containers-prepare-parameter.yaml file and add the ceph_images: false parameter.

   The following is an example of this file with the parameter bolded:

   parameter_defaults:
     ContainerImagePrepare:
     - tag_from_label: {version}-{release}
       set:
         name_prefix: rhosp17-openstack-
         name_suffix: ''
         tag: 17.1_20231214.1
         rhel_containers: false
         neutron_driver: ovn
         ceph_images: false
       push_destination: true

2. Save the containers-prepare-parameter.yaml file.

3. Create a new container images file for use in the overcloud deployment:

   sudo openstack tripleo container image prepare -e containers-prepare-parameter.yaml --output-env-file <new_container_images_file>

   • Replace <new_container_images_file> with the output file that contains the new parameter.
4. Add the new container images file to the list of overcloud deployment environment files.

Procedure

1. Download the RPM packages for installation on the container images.

2. Edit the containers-prepare-parameter.yaml file to update all packages on the container images:

   ContainerImagePrepare:
   - push_destination: true
     ...
     modify_role: tripleo-modify-image
     modify_append_tag: "-updated"
     modify_vars:
       tasks_from: yum_update.yml
       compare_host_packages: true
       yum_repos_dir_path: /etc/yum.repos.d
     ...

3. Save the containers-prepare-parameter.yaml file.
4. Include the containers-prepare-parameter.yaml file when you run the openstack overcloud deploy command.

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

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-rhel9/openstack-nova-compute:latest
   
   USER "root"
   
   COPY customize.sh /tmp/
   RUN /tmp/customize.sh
   
   USER "nova"

Procedure

1. Create a list of all container images:

   $ sudo podman search --limit 1000 "registry.redhat.io/rhosp-rhel9" --format="{{ .Name }}" | sort > satellite_images
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep <ceph_dashboard_image_file>
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep <ceph_image_file>
   $ sudo podman search --limit 1000 "registry.redhat.io/openshift4" | grep ose-prometheus

   • Replace <ceph_dashboard_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:

     • Red Hat Ceph Storage 5: rhceph-5-dashboard-rhel8
     • Red Hat Ceph Storage 6: rhceph-6-dashboard-rhel9

   • Replace <ceph_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:

     • Red Hat Ceph Storage 5: rhceph-5-rhel8

     • Red Hat Ceph Storage 6: rhceph-6-rhel9

       Note

       The openstack-ovn-bgp-agent image is located at registry.redhat.io/rhosp-rhel9/openstack-ovn-bgp-agent-rhel9:17.1.

   • If you plan to install Ceph and enable the Ceph Dashboard, you need the following ose-prometheus containers:

     registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.12
     registry.redhat.io/openshift4/ose-prometheus:v4.12
     registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.12

2. Copy the satellite_images file to a system that contains the Satellite 6 hammer tool. Alternatively, use the instructions in the Hammer CLI Guide to install the hammer tool to the undercloud.

3. Run the following hammer command to create a new product (OSP Containers) in your Satellite organization:

   $ hammer product create \
     --organization "ACME" \
     --name "OSP Containers"

   This custom product will contain your images.

4. Add the overcloud container images from the satellite_images file:

   $ while read IMAGE; do \
     IMAGE_NAME=$(echo $IMAGE | cut -d"/" -f3 | sed "s/openstack-//g") ; \
     IMAGE_NOURL=$(echo $IMAGE | sed "s/registry.redhat.io\///g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE_NOURL \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name $IMAGE_NAME ; done < satellite_images

5. Add the Ceph Storage container image:

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhceph/<ceph_image_name> \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name <ceph_image_name>

   • Replace <ceph_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:

     • Red Hat Ceph Storage 5: rhceph-5-rhel8

     • Red Hat Ceph Storage 6: rhceph-6-rhel9

       Note

       If you want to install the Ceph dashboard, include --name <ceph_dashboard_image_name> in the hammer repository create command:

       $ hammer repository create \
         --organization "ACME" \
         --product "OSP Containers" \
         --content-type docker \
         --url https://registry.redhat.io \
         --docker-upstream-name rhceph/<ceph_dashboard_image_name> \
         --upstream-username USERNAME \
         --upstream-password PASSWORD \
         --name <ceph_dashboard_image_name>

       • Replace <ceph_dashboard_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:

         • Red Hat Ceph Storage 5: rhceph-5-dashboard-rhel8
         • Red Hat Ceph Storage 6: rhceph-6-dashboard-rhel9

6. Synchronize the container images:

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP Containers"

   Wait for the Satellite server to complete synchronization.

   Note

   Depending on your configuration, hammer might ask for your Satellite server username and password. You can configure hammer to automatically login using a configuration file. For more information, see the Authentication section in the Hammer CLI Guide.

7. If your Satellite 6 server uses content views, create a new content view version to incorporate the images and promote it along environments in your application life cycle. This largely depends on how you structure your application lifecycle. For example, if you have an environment called production in your lifecycle and you want the container images to be available in that environment, create a content view that includes the container images and promote that content view to the production environment. For more information, see Managing Content Views.

8. Check the available tags for the base image:

   $ hammer docker tag list --repository "base" \
     --organization "ACME" \
     --lifecycle-environment "production" \
     --product "OSP Containers"

   This command displays tags for the OpenStack Platform container images within a content view for a particular environment.

9. Return to the undercloud and generate a default environment file that prepares images using your Satellite server as a source. Run the following example command to generate the environment file:

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

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

10. Edit the containers-prepare-parameter.yaml file and modify the following parameters:

    • push_destination - Set this to true or false depending on your chosen container image management strategy. If you set this parameter to false, the overcloud nodes pull images directly from the Satellite. If you set this parameter to true, the director pulls the images from the Satellite to the undercloud registry and the overcloud pulls the images from the undercloud registry.
    • namespace - The URL of the registry on the Satellite server.

    • name_prefix - The prefix is based on a Satellite 6 convention. This differs depending on whether you use content views:

      • If you use content views, the structure is [org]-[environment]-[content view]-[product]-. For example: acme-production-myosp17-osp_containers-.
      • If you do not use content views, the structure is [org]-[product]-. For example: acme-osp_containers-.
    • ceph_namespace, ceph_image, ceph_tag - If you use Ceph Storage, include these additional parameters to define the Ceph Storage container image location. Note that ceph_image now includes a Satellite-specific prefix. This prefix is the same value as the name_prefix option.

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

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-rhel9
           name_prefix: openstack-
           name_suffix: ''
           tag: 17.1
           ...
         tag_from_label: "{version}-{release}"

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

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]

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

   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. Log in to the undercloud host as the stack user.

2. Run the openstack tripleo container image prepare default command with the --output-env-file option to generate a file that contains the default image configuration:

   $ sudo openstack tripleo container image prepare default \
   --output-env-file undercloud-container-image-prepare.yaml

3. Modify the undercloud-container-image-prepare.yaml file according to the requirements of your environment.

   1. Remove the tag: parameter so that director can use the tag_from_label: parameter. Director uses this parameter to identify the latest version of each container image, pull each image, and tag each image on the container registry in director.
   2. Remove the Ceph labels for the undercloud.
   3. Ensure that the neutron_driver: parameter is empty. Do not set this parameter to OVN because OVN is not supported on the undercloud.

   4. Include your container image registry credentials:

      ContainerImageRegistryCredentials:
        registry.redhat.io:
          myser: 'p@55w0rd!'

      Note

      You cannot push container images to the undercloud registry on new underclouds because the image-serve registry is not installed yet. You must set the push_destination value to false, or use a custom value, to pull images directly from source. For more information, see Container image preparation parameters.

4. Generate a new container image configuration file that uses the undercloud roles file combined with your custom undercloud-container-image-prepare.yaml file:

   $ sudo openstack tripleo container image prepare \
   -r /usr/share/openstack-tripleo-heat-templates/roles_data_undercloud.yaml \
   -e undercloud-container-image-prepare.yaml \
   --output-env-file undercloud-container-images.yaml

   The undercloud-container-images.yaml file is an environment file that contains a mapping of service parameters to container images. For example, OpenStack Identity (keystone) uses the ContainerKeystoneImage parameter to define its container image:

   ContainerKeystoneImage: undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.1

   Note that the container image tag matches the {version}-{release} format.

5. Include the undercloud-container-images.yaml file in the custom_env_files parameter in the undercloud.conf file. When you run the undercloud installation, the undercloud services use the pinned container image mapping from this file.

Procedure

1. Run the openstack tripleo container image prepare command, which pulls all images from the source defined in the containers-prepare-parameter.yaml file. Include the --output-env-file to specify the output file that will contain the list of pinned container images:

   $ sudo openstack tripleo container image prepare -e /home/stack/templates/containers-prepare-parameter.yaml --output-env-file overcloud-images.yaml

   The overcloud-images.yaml file is an environment file that contains a mapping of service parameters to container images. For example, OpenStack Identity (keystone) uses the ContainerKeystoneImage parameter to define its container image:

   ContainerKeystoneImage: undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.1

   Note that the container image tag matches the {version}-{release} format.

2. Include the containers-prepare-parameter.yaml and overcloud-images.yaml files in that specific order with your environment file collection when you run the openstack overcloud deploy command:

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /home/stack/overcloud-images.yaml \
       ...

Procedure

1. Log in to the undercloud host.

2. Create a new file undercloud-os-net-config.yaml and include the network configuration that you require.

   In the addresses section, include the local_ip, such as 172.20.0.1/26. If TLS is enabled in the undercloud, you must also include the undercloud_public_host, such as 172.20.0.2/32, and the undercloud_admin_host, such as 172.20.0.3/32.

   Here is an example:

   network_config:
   - name: br-ctlplane
     type: ovs_bridge
     use_dhcp: false
     dns_servers:
     - 192.168.122.1
     domain: lab.example.com
     ovs_extra:
     - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
     addresses:
     - ip_netmask: 172.20.0.1/26
     - ip_netmask: 172.20.0.2/32
     - ip_netmask: 172.20.0.3/32
     members:
     - type: interface
       name: nic2

   To create a network bond for a specific interface, use the following sample:

   network_config:
   - name: br-ctlplane
     type: ovs_bridge
     use_dhcp: false
     dns_servers:
     - 192.168.122.1
     domain: lab.example.com
     ovs_extra:
     - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
     addresses:
     - ip_netmask: 172.20.0.1/26
     - ip_netmask: 172.20.0.2/32
     - ip_netmask: 172.20.0.3/32
     members:
     - name: bond-ctlplane
       type: linux_bond
       use_dhcp: false
       bonding_options: "mode=active-backup"
       mtu: 1500
       members:
       - type: interface
         name: nic2
       - type: interface
         name: nic3

3. Include the path to the undercloud-os-net-config.yaml file in the net_config_override parameter in the undercloud.conf file:

   [DEFAULT]
   ...
   net_config_override=undercloud-os-net-config.yaml
   ...

   Note

   Director uses the file that you include in the net_config_override parameter as the template to generate the /etc/os-net-config/config.yaml file. os-net-config manages the interfaces that you define in the template, so you must perform all undercloud network interface customization in this file.

4. Install the undercloud.

Procedure

1. Open your undercloud.conf file.

2. Specify the IPv6 address mode as either stateless or stateful:

   [DEFAULT]
   ipv6_address_mode = <address_mode>
   ...

   • Replace <address_mode> with dhcpv6-stateless or dhcpv6-stateful, based on the mode that your NIC supports.
   Note

   When you use the stateful address mode, the firmware, chain loaders, and operating systems might use different algorithms to generate an ID that the DHCP server tracks. DHCPv6 does not track addresses by MAC, and does not provide the same address back if the identifier value from the requester changes but the MAC address remains the same. Therefore, when you use stateful DHCPv6 you must also complete the next step to configure the network interface.

3. If you configured your undercloud to use stateful DHCPv6, specify the network interface to use for bare metal nodes:

   [DEFAULT]
   ipv6_address_mode = dhcpv6-stateful
   ironic_enabled_network_interfaces = neutron,flat
   ...

4. Set the default network interface for bare metal nodes:

   [DEFAULT]
   ...
   ironic_default_network_interface = neutron
   ...

5. Specify whether or not the undercloud should create a router on the provisioning network:

   [DEFAULT]
   ...
   enable_routed_networks: <true/false>
   ...

   • Replace <true/false> with true to enable routed networks and prevent the undercloud creating a router on the provisioning network. When true, the data center router must provide router advertisements.
   • Replace <true/false> with false to disable routed networks and create a router on the provisioning network.

6. Configure the local IP address, and the IP address for the director Admin API and Public API endpoints over SSL/TLS:

   [DEFAULT]
   ...
   local_ip = <ipv6_address>
   undercloud_admin_host = <ipv6_address>
   undercloud_public_host = <ipv6_address>
   ...

   • Replace <ipv6_address> with the IPv6 address of the undercloud.

7. Optional: Configure the provisioning network that director uses to manage instances:

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   ...

   • Replace <ipv6_address> with the IPv6 address of the network to use for managing instances when not using the default provisioning network.
   • Replace <ipv6_prefix> with the IP address prefix of the network to use for managing instances when not using the default provisioning network.

8. Configure the DHCP allocation range for provisioning nodes:

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   dhcp_start = <ipv6_address_dhcp_start>
   dhcp_end = <ipv6_address_dhcp_end>
   ...

   • Replace <ipv6_address_dhcp_start> with the IPv6 address of the start of the network range to use for the overcloud nodes.
   • Replace <ipv6_address_dhcp_end> with the IPv6 address of the end of the network range to use for the overcloud nodes.

9. Optional: Configure the gateway for forwarding traffic to the external network:

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   dhcp_start = <ipv6_address_dhcp_start>
   dhcp_end = <ipv6_address_dhcp_end>
   gateway = <ipv6_gateway_address>
   ...

   • Replace <ipv6_gateway_address> with the IPv6 address of the gateway when not using the default gateway.

10. Configure the DHCP range to use during the inspection process:

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    ...

    • Replace <ipv6_address_inspection_start> with the IPv6 address of the start of the network range to use during the inspection process.
    • Replace <ipv6_address_inspection_end> with the IPv6 address of the end of the network range to use during the inspection process.
    Note

    This range must not overlap with the range defined by dhcp_start and dhcp_end, but must be in the same IP subnet.

11. Configure an IPv6 nameserver for the subnet:

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    dns_nameservers = <ipv6_dns>

    • Replace <ipv6_dns> with the DNS nameservers specific to the subnet.
12. Use the virt-customize tool to modify the overcloud image to disable the cloud-init network configuration. For more information, see the Red Hat Knowledgebase solution Modifying the Red Hat Linux OpenStack Platform Overcloud Image with virt-customize.

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-9-for-x86_64-baseos-eus-rpms
         - rhel-9-for-x86_64-appstream-eus-rpms
         - rhel-9-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: 9.2

   • 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. To apply the rhsm composable service on a per-role basis, include your configuration in the environment file. For example, you can apply different sets of configurations to Controller nodes, Compute nodes, and Ceph Storage nodes:

   parameter_defaults:
     ControllerParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-9-for-x86_64-baseos-eus-rpms
           - rhel-9-for-x86_64-appstream-eus-rpms
           - rhel-9-for-x86_64-highavailability-eus-rpms
           - openstack-17.1-for-rhel-9-x86_64-rpms
           - fast-datapath-for-rhel-9-x86_64-rpms
           - rhceph-6-tools-for-rhel-9-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 9.2
     ComputeParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-9-for-x86_64-baseos-eus-rpms
           - rhel-9-for-x86_64-appstream-eus-rpms
           - rhel-9-for-x86_64-highavailability-eus-rpms
           - openstack-17.1-for-rhel-9-x86_64-rpms
           - rhceph-6-tools-for-rhel-9-x86_64-rpms
           - fast-datapath-for-rhel-9-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 9.2
     CephStorageParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-9-for-x86_64-baseos-rpms
           - rhel-9-for-x86_64-appstream-rpms
           - rhel-9-for-x86_64-highavailability-rpms
           - openstack-17.1-deployment-tools-for-rhel-9-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
         rhsm_method: "portal"
         rhsm_release: 9.2

   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.

4. 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-9-for-x86_64-baseos-eus-rpms
           - rhel-9-for-x86_64-appstream-eus-rpms
           - rhel-9-for-x86_64-highavailability-eus-rpms
           - openstack-17.1-for-rhel-9-x86_64-rpms
           - fast-datapath-for-rhel-9-x86_64-rpms
           - rhceph-6-tools-for-rhel-9-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 9.2
     ComputeParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-9-for-x86_64-baseos-eus-rpms
           - rhel-9-for-x86_64-appstream-eus-rpms
           - rhel-9-for-x86_64-highavailability-eus-rpms
           - openstack-17.1-for-rhel-9-x86_64-rpms
           - rhceph-6-tools-for-rhel-9-x86_64-rpms
           - fast-datapath-for-rhel-9-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 9.2
     CephStorageParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-9-for-x86_64-baseos-rpms
           - rhel-9-for-x86_64-appstream-rpms
           - rhel-9-for-x86_64-highavailability-rpms
           - openstack-17.1-deployment-tools-for-rhel-9-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
         rhsm_method: "portal"
         rhsm_release: 9.2

   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: 9.2

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

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

   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

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-9-for-x86_64-baseos-eus-rpms
         - rhel-9-for-x86_64-appstream-eus-rpms
         - rhel-9-for-x86_64-highavailability-eus-rpms
         - openstack-17.1-for-rhel-9-x86_64-rpms
         - fast-datapath-for-rhel-9-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 9.2
           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 }}"

   • 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

   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. View the log with the less command:

   $ less ~/ansible.log

Procedure

1. Change to the config-download working directory for your overcloud, usually named overcloud:

   $ cd ~/config-download/overcloud

2. Run the git log command to list the commits in your working directory. You can also format the log output to show the date:

   $ git log --format=format:"%h%x09%cd%x09"
   a7e9063 Mon Oct 8 21:17:52 2018 +1000
   dfb9d12 Fri Oct 5 20:23:44 2018 +1000
   d0a910b Wed Oct 3 19:30:16 2018 +1000
   ...

   By default, the most recent commit appears first.

3. Run the git diff command against two commit hashes to see all changes between the deployments:

   $ git diff a7e9063 dfb9d12

Procedure

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

2. Source the stackrc file:

   $ source ~/stackrc

3. Run the deployment command. Include any environment files that you require for your overcloud:

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...

4. Wait until the deployment process completes.

Procedure

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

2. Source the stackrc file:

   $ source ~/stackrc

3. Run the deployment command with the --stack-only option. Include any environment files you require for your overcloud:

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --stack-only

4. Wait until the provisioning process completes.

5. Enable SSH access from the undercloud to the overcloud for the tripleo-admin user. The config-download process uses the tripleo-admin user to perform the Ansible-based configuration:

   $ openstack overcloud admin authorize

6. Perform any manual pre-configuration tasks on nodes. If you use Ansible for configuration, use the tripleo-admin user to access the nodes.

7. Run the deployment command with the --config-download-only option. Include any environment files required for your overcloud:

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --config-download-only

8. Wait until the configuration process completes.

Procedure

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

2. Run the ansible-playbook-command.sh script.

   You can pass additional Ansible arguments to this script, which are then passed unchanged to the ansible-playbook command. This makes it possible to take advantage of Ansible features, such as check mode (--check), limiting hosts (--limit), or overriding variables (-e). For example:

   $ ./ansible-playbook-command.sh --limit Controller

   Warning

   When --limit is used to deploy at scale, only hosts included in the execution are added to the SSH known_hosts file across the nodes. Therefore, some operations, such as live migration, may not work across nodes that are not in the known_hosts file.

   Note

   To ensure that the /etc/hosts file, on all nodes, is up-to-date, run the following command as the stack user:

   (undercloud)$ cd /home/stack/overcloud-deploy/overcloud/config-download/overcloud
   (undercloud)$ ANSIBLE_REMOTE_USER="tripleo-admin" ansible allovercloud \
     -i /home/stack/overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml \
     -m include_role \
     -a name=tripleo_hosts_entries \
     -e @global_vars.yaml

3. Wait until the configuration process completes.

   Additional information

   • The working directory contains a playbook called deploy_steps_playbook.yaml, which manages the overcloud configuration tasks. To view this playbook, run the following command:

     $ less deploy_steps_playbook.yaml

     The playbook uses various task files contained in the working directory. Some task files are common to all OpenStack Platform roles and some are specific to certain OpenStack Platform roles and servers.

   • The working directory also contains sub-directories that correspond to each role that you define in your overcloud roles_data file. For example:

     $ ls Controller/

     Each OpenStack Platform role directory also contains sub-directories for individual servers of that role type. The directories use the composable role hostname format:

     $ ls Controller/overcloud-controller-0

   • The Ansible tasks in deploy_steps_playbook.yaml are tagged. To see the full list of tags, use the CLI option --list-tags with ansible-playbook:

     $ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml

     Then apply tagged configuration using the --tags, --skip-tags, or --start-at-task with the ansible-playbook-command.sh script:

     $ ./ansible-playbook-command.sh --tags overcloud

4. When you run the config-download playbooks against the overcloud, you might receive a message regarding the SSH fingerprint for each host. To avoid these messages, include --ssh-common-args="-o StrictHostKeyChecking=no" when you run the ansible-playbook-command.sh script:

   $ ./ansible-playbook-command.sh --tags overcloud --ssh-common-args="-o StrictHostKeyChecking=no"

Procedure

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

2. Source the stackrc file:

   $ source ~/stackrc

3. Run the deployment command with the --stack-only option. Include any environment files required for your overcloud:

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --stack-only

4. Wait until the provisioning process completes.

5. Enable SSH access from the undercloud to the overcloud for the tripleo-admin user. The config-download process uses the tripleo-admin user to perform the Ansible-based configuration:

   $ openstack overcloud admin authorize

6. Generate the config-download files:

   $ openstack overcloud deploy \
     --stack overcloud --stack-only \
     --config-dir  ~/overcloud-deploy/overcloud/config-download/overcloud/

   • --stack specifies the name of the overcloud.
   • --stack-only ensures that the command only deploys the heat stack and skips any software configuration.
   • --config-dir specifies the location of the config-download files.

7. Change to the directory that contains your config-download files:

   $ cd ~/config-download

8. Generate a static inventory file:

   $ tripleo-ansible-inventory \
     --stack <overcloud> \
     --ansible_ssh_user tripleo-admin \
     --static-yaml-inventory inventory.yaml

   • Replace <overcloud> with the name of your overcloud.

9. Use the ~/overcloud-deploy/overcloud/config-download/overcloud files and the static inventory file to perform a configuration. To execute the deployment playbook, run the ansible-playbook command:

   $ ansible-playbook \
     -i inventory.yaml \
     -e gather_facts=true \
     -e @global_vars.yaml \
     --private-key ~/.ssh/id_rsa \
     --become \
     ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml

   Note

   When you run the config-download/overcloud playbooks against the overcloud, you might receive a message regarding the SSH fingerprint for each host. To avoid these messages, include --ssh-common-args="-o StrictHostKeyChecking=no" in your ansible-playbook command:

   $ ansible-playbook \
     -i inventory.yaml \
     -e gather_facts=true \
     -e @global_vars.yaml \
     --private-key ~/.ssh/id_rsa \
     --ssh-common-args="-o StrictHostKeyChecking=no" \
     --become \
     --tags overcloud \
     ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml

10. Wait until the configuration process completes.

11. Generate an overcloudrc file manually from the ansible-based configuration:

    $ openstack action execution run \
      --save-result \
      --run-sync \
      tripleo.deployment.overcloudrc \
      '{"container":"overcloud"}' \
      | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

12. Manually set the deployment status to success:

    $ openstack workflow execution create tripleo.deployment.v1.set_deployment_status_success '{"plan": "<overcloud>"}'

    • Replace <overcloud> with the name of your overcloud.

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 10.3.4, “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/*

      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

      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 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']
         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]}

   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. In this case, you want to apply the configuration when the overcloud is created. Possible actions include CREATE, UPDATE, DELETE, SUSPEND, and RESUME.
   • 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

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 \
       ...

   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']
         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]}

   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. In this case, you only apply the configuration when the overcloud is created. Possible actions include CREATE, UPDATE, DELETE, SUSPEND, and RESUME.
   • 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

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 \
       ...

   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']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}

   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. In this case, you want apply the configuration when the overcloud is created. Possible actions include CREATE, UPDATE, DELETE, SUSPEND, and RESUME.
   • 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

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 \
       ...

   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

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

   This command returns a system UUID. For example:

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

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" ]}}'

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}

   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

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 \
       ...

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