Chapter 6. Preparing for director installation

Procedure

1. Log in to your undercloud as the root user.

2. Create the stack user:

   [root@director ~]# useradd stack

3. Set a password for the user:

   [root@director ~]# passwd stack

4. Disable password requirements when using sudo:

   [root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@director ~]# chmod 0440 /etc/sudoers.d/stack

5. Switch to the new stack user:

   [root@director ~]# su - stack
   [stack@director ~]$

6. Create directories for system images and heat templates:

   [stack@director ~]$ mkdir ~/images
   [stack@director ~]$ mkdir ~/templates

   Director uses system images and heat templates to create the overcloud environment. Red Hat recommends creating these directories to help you organize your local file system.

7. Check the base and full hostname of the undercloud:

   [stack@director ~]$ hostname
   [stack@director ~]$ hostname -f

   If either of the previous commands do not report the correct fully-qualified hostname or report an error, use hostnamectl to set a hostname:

   [stack@director ~]$ sudo hostnamectl set-hostname undercloud.example.com

8. If you are not using a DNS server that can resolve the fully qualified domain name (FQDN) of the undercloud host, edit the /etc/hosts and include an entry for the system hostname. The IP address in /etc/hosts must match the address that you plan to use for your undercloud public API. For example, if the system uses undercloud.example.com as the FQDN and uses 10.0.0.1 for its IP address, add the following line to the /etc/hosts file:

   10.0.0.1  undercloud.example.com undercloud

9. If you plan for the Red Hat OpenStack Platform director to be on a separate domain than the overcloud or its identity provider, then you must add the additional domains to /etc/resolv.conf:

   search overcloud.com idp.overcloud.com

Procedure

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

2. Register your system either with the Red Hat Content Delivery Network or with a Red Hat Satellite. For example, run the following command to register the system to the Content Delivery Network. Enter your Customer Portal user name and password when prompted:

   [stack@director ~]$ sudo subscription-manager register

3. Find the entitlement pool ID for Red Hat OpenStack Platform (RHOSP) director:

   [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
                        Red Hat Virtualization
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             Valid-Pool-Number-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

4. Locate the Pool ID value and attach the Red Hat OpenStack Platform 17.0 entitlement:

   [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

5. Lock the undercloud to Red Hat Enterprise Linux 9.0:

   $ sudo subscription-manager release --set=9.0

Procedure

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

2. Disable all default repositories, and enable the required Red Hat Enterprise Linux repositories:

   [stack@director ~]$ sudo subscription-manager repos --disable=*
   [stack@director ~]$ sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-eus-rpms --enable=rhel-9-for-x86_64-appstream-eus-rpms --enable=rhel-9-for-x86_64-highavailability-eus-rpms --enable=openstack-17-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms

   These repositories contain packages that the director installation requires.

3. Perform an update on your system to ensure that you have the latest base system packages:

   [stack@director ~]$ sudo dnf update -y
   [stack@director ~]$ sudo reboot

Procedure

1. Install the command line tools for director installation and configuration:

   [stack@director ~]$ sudo dnf install -y python3-tripleoclient

Procedure

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

2. Generate the default container image preparation file:

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

   This command includes the following additional options:

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

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

     Note

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

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

Procedure

1. 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: 16.2
           ...
         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. Edit the containers-prepare-parameter.yaml file to exclude the Ceph Storage containers:

   parameter_defaults:
     ContainerImagePrepare:
     - push_destination: true
       excludes:
         - ceph
         - prometheus
       set:
         …​

   The excludes parameter uses regular expressions to exclude any container images that contain the ceph or prometheus strings.

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

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 rhceph-5-dashboard-rhel8
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-5-rhel8
   $ sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheus

   • 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.6
     registry.redhat.io/openshift4/ose-prometheus:v4.6
     registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6

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/rhceph-5-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-5-rhel8

   Note

   If you want to install the Ceph dashboard, include --name rhceph-5-dashboard-rhel8 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/rhceph-5-dashboard-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-5-dashboard-rhel8

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