Customizing your Red Hat OpenStack Platform deployment

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. Set it to true if an external data center router is attached to the provisioning network. When true`, the data center router must provide router advertisements. Also, the M` and O` flag settings of the data center router must be consistent with the ipv6_address_mode` setting.
   • Replace <true/false> with false to disable routed networks and create a router on the provisioning network. Set it to false if no external data center routers are attached to 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-e4s-rpms
         - rhel-9-for-x86_64-appstream-e4s-rpms
         - rhel-9-for-x86_64-highavailability-e4s-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-e4s-rpms
           - rhel-9-for-x86_64-appstream-e4s-rpms
           - rhel-9-for-x86_64-highavailability-e4s-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-e4s-rpms
           - rhel-9-for-x86_64-appstream-e4s-rpms
           - rhel-9-for-x86_64-highavailability-e4s-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 Enhanced Extended Update Service (EEUS) 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-e4s-rpms
           - rhel-9-for-x86_64-appstream-e4s-rpms
           - rhel-9-for-x86_64-highavailability-e4s-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-e4s-rpms
           - rhel-9-for-x86_64-appstream-e4s-rpms
           - rhel-9-for-x86_64-highavailability-e4s-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 Enhanced Extended Update Service (EEUS) 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-e4s-rpms
         - rhel-9-for-x86_64-appstream-e4s-rpms
         - rhel-9-for-x86_64-highavailability-e4s-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

   If you used --limit ensure that the /etc/hosts file is up-to-date on all nodes by running the following commands 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

   If you used --limit on a set of Compute nodes, also run the following commands to ensure that live migration works on Compute nodes that were not added to the known_hosts file. Include the Compute nodes that need to participate in live migrations. All nodes are included by default in the allovercloud Ansible group.

   (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_ssh_known_hosts \
     -e @global_vars.yaml

3. Wait until the configuration process completes.

Procedure

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

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Provision the overcloud nodes:

   $ openstack overcloud node provision \
   --stack <stackname> \
   --output <deployment_file> \
   /home/stack/templates/overcloud-baremetal-deploy.yaml

   • Replace <stackname> with the name of the stack for which the nodes are provisioned. The default value is overcloud.
   • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-nodes-deployed.yaml.

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

5. Navigate to the directory that contains your config-download files:

   $ cd ~/overcloud-deploy/<stackname>/config-download/<stackname>

6. Use the ~/overcloud-deploy/<stackname>/config-download/<stackname> files to add a custom configuration. To execute the deployment playbook, run the ansible-playbook command:

   $ ANSIBLE_PRIVATE_KEY_FILE="/home/stack/.ssh/id_rsa_tripleo" ansible-playbook \
     -i ~/overcloud-deploy/<stackname>/config-download/<stackname>/tripleo-ansible-inventory.yaml \
     -e gather_facts=true \
     -e @global_vars.yaml \
     --private-key ~/.ssh/id_rsa \
     --become \
     ~/overcloud-deploy/<stackname>/config-download/<stackname>/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_PRIVATE_KEY_FILE="/home/stack/.ssh/id_rsa_tripleo" ansible-playbook \
     -i ~/overcloud-deploy/<stackname>/config-download/<stackname>/tripleo-ansible-inventory.yaml \
     -e gather_facts=true \
     -e @global_vars.yaml \
     --private-key ~/.ssh/id_rsa \
     --ssh-common-args="-o StrictHostKeyChecking=no" \
     --become \
     ~/overcloud-deploy/<stackname>/config-download/<stackname>/deploy_steps_playbook.yaml

7. Wait until the configuration process completes.