Chapter 21. Installing on OpenStack

Procedure

1. Save the following script to your machine:

   #!/usr/bin/env bash
   
   set -Eeuo pipefail
   
   declare catalog san
   catalog="$(mktemp)"
   san="$(mktemp)"
   readonly catalog san
   
   declare invalid=0
   
   openstack catalog list --format json --column Name --column Endpoints \
   	| jq -r '.[] | .Name as $name | .Endpoints[] | select(.interface=="public") | [$name, .interface, .url] | join(" ")' \
   	| sort \
   	> "$catalog"
   
   while read -r name interface url; do
   	# Ignore HTTP
   	if [[ ${url#"http://"} != "$url" ]]; then
   		continue
   	fi
   
   	# Remove the schema from the URL
   	noschema=${url#"https://"}
   
   	# If the schema was not HTTPS, error
   	if [[ "$noschema" == "$url" ]]; then
   		echo "ERROR (unknown schema): $name $interface $url"
   		exit 2
   	fi
   
   	# Remove the path and only keep host and port
   	noschema="${noschema%%/*}"
   	host="${noschema%%:*}"
   	port="${noschema##*:}"
   
   	# Add the port if was implicit
   	if [[ "$port" == "$host" ]]; then
   		port='443'
   	fi
   
   	# Get the SAN fields
   	openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
   		| openssl x509 -noout -ext subjectAltName \
   		> "$san"
   
   	# openssl returns the empty string if no SAN is found.
   	# If a SAN is found, openssl is expected to return something like:
   	#
   	#    X509v3 Subject Alternative Name:
   	#        DNS:standalone, DNS:osp1, IP Address:192.168.2.1, IP Address:10.254.1.2
   	if [[ "$(grep -c "Subject Alternative Name" "$san" || true)" -gt 0 ]]; then
   		echo "PASS: $name $interface $url"
   	else
   		invalid=$((invalid+1))
   		echo "INVALID: $name $interface $url"
   	fi
   done < "$catalog"
   
   # clean up temporary files
   rm "$catalog" "$san"
   
   if [[ $invalid -gt 0 ]]; then
   	echo "${invalid} legacy certificates were detected. Update your certificates to include a SAN field."
   	exit 1
   else
   	echo "All HTTPS certificates for this cloud are valid."
   fi

2. Run the script.
3. Replace any certificates that the script reports as INVALID with certificates that contain SAN fields.

1. As an administrator in the RHOSP CLI, add the swiftoperator role to the account that will access Swift:

   $ openstack role add --user <user> --project <project> swiftoperator

Procedure

1. Create a YAML file that specifies the storage class and availability zone to use. For example:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: custom-csi-storageclass
   provisioner: cinder.csi.openstack.org
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     availability: <availability_zone_name>

   Note

   OpenShift Container Platform does not verify the existence of the availability zone you choose. Verify the name of the availability zone before you apply the configuration.

2. From a command line, apply the configuration:

   $ oc apply -f <storage_class_file_name>

   Example output

   storageclass.storage.k8s.io/custom-csi-storageclass created

3. Create a YAML file that specifies a persistent volume claim (PVC) that uses your storage class and the openshift-image-registry namespace. For example:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: csi-pvc-imageregistry
     namespace: openshift-image-registry 1
     annotations:
       imageregistry.openshift.io: "true"
   spec:
     accessModes:
     - ReadWriteOnce
     volumeMode: Filesystem
     resources:
       requests:
         storage: 100Gi 2
     storageClassName: <your_custom_storage_class> 3

   1

   Enter the namespace openshift-image-registry. This namespace allows the Cluster Image Registry Operator to consume the PVC.

   2

   Optional: Adjust the volume size.

   3

   Enter the name of the storage class that you created.

4. From a command line, apply the configuration:

   $ oc apply -f <pvc_file_name>

   Example output

   persistentvolumeclaim/csi-pvc-imageregistry created

5. Replace the original persistent volume claim in the image registry configuration with the new claim:

   $ oc patch configs.imageregistry.operator.openshift.io/cluster --type 'json' -p='[{"op": "replace", "path": "/spec/storage/pvc/claim", "value": "csi-pvc-imageregistry"}]'

   Example output

   config.imageregistry.operator.openshift.io/cluster patched

   Over the next several minutes, the configuration is updated.

1. Verify that the PVC claim value is identical to the name that you provided in your PVC definition:

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   Example output

   ...
   status:
       ...
       managementState: Managed
       pvc:
         claim: csi-pvc-imageregistry
   ...

2. Verify that the status of the PVC is Bound:

   $ oc get pvc -n openshift-image-registry csi-pvc-imageregistry

   Example output

   NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS             AGE
   csi-pvc-imageregistry  Bound    pvc-72a8f9c9-f462-11e8-b6b6-fa163e18b7b5   100Gi      RWO            custom-csi-storageclass  11m

Procedure

1. Using the RHOSP CLI, verify the name and ID of the 'External' network:

   $ openstack network list --long -c ID -c Name -c "Router Type"

   Example output

   +--------------------------------------+----------------+-------------+
   | ID                                   | Name           | Router Type |
   +--------------------------------------+----------------+-------------+
   | 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
   +--------------------------------------+----------------+-------------+

Procedure

1. Create the clouds.yaml file:

   • If your RHOSP distribution includes the Horizon web UI, generate a clouds.yaml file in it.

     Important

     Remember to add a password to the auth field. You can also keep secrets in a separate file from clouds.yaml.

   • If your RHOSP distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about clouds.yaml, see Config files in the RHOSP documentation.

     clouds:
       shiftstack:
         auth:
           auth_url: http://10.10.14.42:5000/v3
           project_name: shiftstack
           username: <username>
           password: <password>
           user_domain_name: Default
           project_domain_name: Default
       dev-env:
         region_name: RegionOne
         auth:
           username: <username>
           password: <password>
           project_name: 'devonly'
           auth_url: 'https://10.10.14.22:5001/v2.0'

2. If your RHOSP installation uses self-signed certificate authority (CA) certificates for endpoint authentication:

   1. Copy the certificate authority file to your machine.

   2. Add the cacerts key to the clouds.yaml file. The value must be an absolute, non-root-accessible path to the CA certificate:

      clouds:
        shiftstack:
          ...
          cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"

      Tip

      After you run the installer with a custom CA certificate, you can update the certificate by editing the value of the ca-cert.pem key in the cloud-provider-config keymap. On a command line, run:

      $ oc edit configmap -n openshift-config cloud-provider-config

3. Place the clouds.yaml file in one of the following locations:

   1. The value of the OS_CLIENT_CONFIG_FILE environment variable
   2. The current directory
   3. A Unix-specific user configuration directory, for example ~/.config/openstack/clouds.yaml

   4. A Unix-specific site configuration directory, for example /etc/openstack/clouds.yaml

      The installation program searches for clouds.yaml in that order.

Procedure

1. If you have not already generated manifest files for your cluster, generate them by running the following command:

   $ openshift-install --dir <destination_directory> create manifests

2. In a text editor, open the cloud-provider configuration manifest file. For example:

   $ vi openshift/manifests/cloud-provider-config.yaml

3. Modify the options according to the CCM reference guide.

   Configuring Octavia for load balancing is a common case. For example:

   #...
   [LoadBalancer]
   lb-provider = "amphora" 1
   floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a" 2
   create-monitor = True 3
   monitor-delay = 10s 4
   monitor-timeout = 10s 5
   monitor-max-retries = 1 6
   #...

   1

   This property sets the Octavia provider that your load balancer uses. It accepts "ovn" or "amphora" as values. If you choose to use OVN, you must also set lb-method to SOURCE_IP_PORT.

   2

   This property is required if you want to use multiple external networks with your cluster. The cloud provider creates floating IP addresses on the network that is specified here.

   3

   This property controls whether the cloud provider creates health monitors for Octavia load balancers. Set the value to True to create health monitors. As of RHOSP 16.2, this feature is only available for the Amphora provider.

   4

   This property sets the frequency with which endpoints are monitored. The value must be in the time.ParseDuration() format. This property is required if the value of the create-monitor property is True.

   5

   This property sets the time that monitoring requests are open before timing out. The value must be in the time.ParseDuration() format. This property is required if the value of the create-monitor property is True.

   6

   This property defines how many successful monitoring requests are required before a load balancer is marked as online. The value must be an integer. This property is required if the value of the create-monitor property is True.

   Important

   Prior to saving your changes, verify that the file is structured correctly. Clusters might fail if properties are not placed in the appropriate section.

   Important

   You must set the value of the create-monitor property to True if you use services that have the value of the .spec.externalTrafficPolicy property set to Local. The OVN Octavia provider in RHOSP 16.2 does not support health monitors. Therefore, services that have ETP parameter values set to Local might not respond when the lb-provider value is set to "ovn".

4. Save the changes to the file and proceed with installation.

   Tip

   You can update your cloud provider configuration after you run the installer. On a command line, run:

   $ oc edit configmap -n openshift-config cloud-provider-config

   After you save your changes, your cluster will take some time to reconfigure itself. The process is complete if none of your nodes have a SchedulingDisabled status.

Procedure

1. Access the Infrastructure Provider page on the OpenShift Cluster Manager site. If you have a Red Hat account, log in with your credentials. If you do not, create an account.
2. Select your infrastructure provider.

3. Navigate to the page for your installation type, download the installation program that corresponds with your host operating system and architecture, and place the file in the directory where you will store the installation configuration files.

   Important

   The installation program creates several files on the computer that you use to install your cluster. You must keep the installation program and the files that the installation program creates after you finish installing the cluster. Both files are required to delete the cluster.

   Important

   Deleting the files created by the installation program does not remove your cluster, even if the cluster failed during installation. To remove your cluster, complete the OpenShift Container Platform uninstallation procedures for your specific cloud provider.

4. Extract the installation program. For example, on a computer that uses a Linux operating system, run the following command:

   $ tar -xvf openshift-install-linux.tar.gz

5. Download your installation pull secret from Red Hat OpenShift Cluster Manager. This pull secret allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for OpenShift Container Platform components.

Procedure

1. Create the install-config.yaml file.

   1. Change to the directory that contains the installation program and run the following command:

      $ ./openshift-install create install-config --dir <installation_directory> 1

      1

      For <installation_directory>, specify the directory name to store the files that the installation program creates.

      When specifying the directory:

      • Verify that the directory has the execute permission. This permission is required to run Terraform binaries under the installation directory.
      • Use an empty directory. Some installation assets, such as bootstrap X.509 certificates, have short expiration intervals, therefore you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OpenShift Container Platform version.

   2. At the prompts, provide the configuration details for your cloud:

      1. Optional: Select an SSH key to use to access your cluster machines.

         Note

         For production OpenShift Container Platform clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your ssh-agent process uses.

      2. Select openstack as the platform to target.
      3. Specify the Red Hat OpenStack Platform (RHOSP) external network name to use for installing the cluster.
      4. Specify the floating IP address to use for external access to the OpenShift API.
      5. Specify a RHOSP flavor with at least 16 GB RAM to use for control plane nodes and 8 GB RAM for compute nodes.
      6. Select the base domain to deploy the cluster to. All DNS records will be sub-domains of this base and will also include the cluster name.
      7. Enter a name for your cluster. The name must be 14 or fewer characters long.
2. Modify the install-config.yaml file. You can find more information about the available parameters in the "Installation configuration parameters" section.

3. Back up the install-config.yaml file so that you can use it to install multiple clusters.

   Important

   The install-config.yaml file is consumed during the installation process. If you want to reuse the file, you must back it up now.

Procedure

1. If you do not have an existing SSH key pair on your local machine to use for authentication onto your cluster nodes, create one. For example, on a computer that uses a Linux operating system, run the following command:

   $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1

   1

   Specify the path and file name, such as ~/.ssh/id_ed25519, of the new SSH key. If you have an existing key pair, ensure your public key is in the your ~/.ssh directory.

   Note

   If you plan to install an OpenShift Container Platform cluster that uses the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures, do not create a key that uses the ed25519 algorithm. Instead, create a key that uses the rsa or ecdsa algorithm.

2. View the public SSH key:

   $ cat <path>/<file_name>.pub

   For example, run the following to view the ~/.ssh/id_ed25519.pub public key:

   $ cat ~/.ssh/id_ed25519.pub

3. Add the SSH private key identity to the SSH agent for your local user, if it has not already been added. SSH agent management of the key is required for password-less SSH authentication onto your cluster nodes, or if you want to use the ./openshift-install gather command.

   Note

   On some distributions, default SSH private key identities such as ~/.ssh/id_rsa and ~/.ssh/id_dsa are managed automatically.

   1. If the ssh-agent process is not already running for your local user, start it as a background task:

      $ eval "$(ssh-agent -s)"

      Example output

      Agent pid 31874

      Note

      If your cluster is in FIPS mode, only use FIPS-compliant algorithms to generate the SSH key. The key must be either RSA or ECDSA.

4. Add your SSH private key to the ssh-agent:

   $ ssh-add <path>/<file_name> 1

   1

   Specify the path and file name for your SSH private key, such as ~/.ssh/id_ed25519

   Example output

   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

Procedure

1. In the cluster environment, export the administrator’s kubeconfig file:

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   For <installation_directory>, specify the path to the directory that you stored the installation files in.

   The kubeconfig file contains information about the cluster that is used by the CLI to connect a client to the correct cluster and API server.

2. View the control plane and compute machines created after a deployment:

   $ oc get nodes

3. View your cluster’s version:

   $ oc get clusterversion

4. View your Operators' status:

   $ oc get clusteroperator

5. View all running pods in the cluster:

   $ oc get pods -A

Procedure

1. Export the kubeadmin credentials:

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   For <installation_directory>, specify the path to the directory that you stored the installation files in.

2. Verify you can run oc commands successfully using the exported configuration:

   $ oc whoami

   Example output

   system:admin

Procedure

1. On a command line, add the repositories:

   1. Register with Red Hat Subscription Manager:

      $ sudo subscription-manager register # If not done already

   2. Pull the latest subscription data:

      $ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already

   3. Disable the current repositories:

      $ sudo subscription-manager repos --disable=* # If not done already

   4. Add the required repositories:

      $ sudo subscription-manager repos \
        --enable=rhel-8-for-x86_64-baseos-rpms \
        --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
        --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
        --enable=rhel-8-for-x86_64-appstream-rpms

2. Install the modules:

   $ sudo yum install python3-openstackclient ansible python3-openstacksdk python3-netaddr ansible-collections-openstack

3. Ensure that the python command points to python3:

   $ sudo alternatives --set python /usr/bin/python3

Procedure

1. Access the Infrastructure Provider page on the OpenShift Cluster Manager site. If you have a Red Hat account, log in with your credentials. If you do not, create an account.
2. Select your infrastructure provider.

3. Navigate to the page for your installation type, download the installation program that corresponds with your host operating system and architecture, and place the file in the directory where you will store the installation configuration files.

   Important

   The installation program creates several files on the computer that you use to install your cluster. You must keep the installation program and the files that the installation program creates after you finish installing the cluster. Both files are required to delete the cluster.

   Important

   Deleting the files created by the installation program does not remove your cluster, even if the cluster failed during installation. To remove your cluster, complete the OpenShift Container Platform uninstallation procedures for your specific cloud provider.

4. Extract the installation program. For example, on a computer that uses a Linux operating system, run the following command:

   $ tar -xvf openshift-install-linux.tar.gz

5. Download your installation pull secret from Red Hat OpenShift Cluster Manager. This pull secret allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for OpenShift Container Platform components.

Procedure

1. If you do not have an existing SSH key pair on your local machine to use for authentication onto your cluster nodes, create one. For example, on a computer that uses a Linux operating system, run the following command:

   $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1

   1

   Specify the path and file name, such as ~/.ssh/id_ed25519, of the new SSH key. If you have an existing key pair, ensure your public key is in the your ~/.ssh directory.

   Note

   If you plan to install an OpenShift Container Platform cluster that uses the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures, do not create a key that uses the ed25519 algorithm. Instead, create a key that uses the rsa or ecdsa algorithm.

2. View the public SSH key:

   $ cat <path>/<file_name>.pub

   For example, run the following to view the ~/.ssh/id_ed25519.pub public key:

   $ cat ~/.ssh/id_ed25519.pub

3. Add the SSH private key identity to the SSH agent for your local user, if it has not already been added. SSH agent management of the key is required for password-less SSH authentication onto your cluster nodes, or if you want to use the ./openshift-install gather command.

   Note

   On some distributions, default SSH private key identities such as ~/.ssh/id_rsa and ~/.ssh/id_dsa are managed automatically.

   1. If the ssh-agent process is not already running for your local user, start it as a background task:

      $ eval "$(ssh-agent -s)"

      Example output

      Agent pid 31874

      Note

      If your cluster is in FIPS mode, only use FIPS-compliant algorithms to generate the SSH key. The key must be either RSA or ECDSA.

4. Add your SSH private key to the ssh-agent:

   $ ssh-add <path>/<file_name> 1

   1

   Specify the path and file name for your SSH private key, such as ~/.ssh/id_ed25519

   Example output

   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

Procedure

1. Log in to the Red Hat Customer Portal’s Product Downloads page.

2. Under Version, select the most recent release of OpenShift Container Platform 4.15 for Red Hat Enterprise Linux (RHEL) 8.

   Important

   The RHCOS images might not change with every release of OpenShift Container Platform. You must download images with the highest version that is less than or equal to the OpenShift Container Platform version that you install. Use the image versions that match your OpenShift Container Platform version if they are available.

3. Download the Red Hat Enterprise Linux CoreOS (RHCOS) - OpenStack Image (QCOW).

4. Decompress the image.

   Note

   You must decompress the RHOSP image before the cluster can use it. The name of the downloaded file might not contain a compression extension, like .gz or .tgz. To find out if or how the file is compressed, in a command line, enter:

   $ file <name_of_downloaded_file>

5. From the image that you downloaded, create an image that is named rhcos in your cluster by using the RHOSP CLI:

   $ openstack image create --container-format=bare --disk-format=qcow2 --file rhcos-${RHCOS_VERSION}-openstack.qcow2 rhcos

   Important

   Depending on your RHOSP environment, you might be able to upload the image in either .raw or .qcow2 formats. If you use Ceph, you must use the .raw format.

   Warning

   If the installation program finds multiple images with the same name, it chooses one of them at random. To avoid this behavior, create unique names for resources in RHOSP.

Procedure

1. Using the RHOSP CLI, verify the name and ID of the 'External' network:

   $ openstack network list --long -c ID -c Name -c "Router Type"

   Example output

   +--------------------------------------+----------------+-------------+
   | ID                                   | Name           | Router Type |
   +--------------------------------------+----------------+-------------+
   | 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
   +--------------------------------------+----------------+-------------+

Procedure

1. Create the clouds.yaml file:

   • If your RHOSP distribution includes the Horizon web UI, generate a clouds.yaml file in it.

     Important

     Remember to add a password to the auth field. You can also keep secrets in a separate file from clouds.yaml.

   • If your RHOSP distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about clouds.yaml, see Config files in the RHOSP documentation.

     clouds:
       shiftstack:
         auth:
           auth_url: http://10.10.14.42:5000/v3
           project_name: shiftstack
           username: <username>
           password: <password>
           user_domain_name: Default
           project_domain_name: Default
       dev-env:
         region_name: RegionOne
         auth:
           username: <username>
           password: <password>
           project_name: 'devonly'
           auth_url: 'https://10.10.14.22:5001/v2.0'

2. If your RHOSP installation uses self-signed certificate authority (CA) certificates for endpoint authentication:

   1. Copy the certificate authority file to your machine.

   2. Add the cacerts key to the clouds.yaml file. The value must be an absolute, non-root-accessible path to the CA certificate:

      clouds:
        shiftstack:
          ...
          cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"

      Tip

      After you run the installer with a custom CA certificate, you can update the certificate by editing the value of the ca-cert.pem key in the cloud-provider-config keymap. On a command line, run:

      $ oc edit configmap -n openshift-config cloud-provider-config

3. Place the clouds.yaml file in one of the following locations:

   1. The value of the OS_CLIENT_CONFIG_FILE environment variable
   2. The current directory
   3. A Unix-specific user configuration directory, for example ~/.config/openstack/clouds.yaml

   4. A Unix-specific site configuration directory, for example /etc/openstack/clouds.yaml

      The installation program searches for clouds.yaml in that order.

Procedure

1. For a dual stack cluster deployment, edit the inventory.yaml file and uncomment the os_subnet6 attribute.

2. On a command line, create the network resources by running the following command:

   $ ansible-playbook -i inventory.yaml network.yaml

   Note

   The API and Ingress VIP fields will be overwritten in the inventory.yaml playbook with the IP addresses assigned to the network ports.

   Note

   The resources created by the network.yaml playbook are deleted by the down-network.yaml playbook.

Procedure

1. Create the install-config.yaml file.

   1. Change to the directory that contains the installation program and run the following command:

      $ ./openshift-install create install-config --dir <installation_directory> 1

      1

      For <installation_directory>, specify the directory name to store the files that the installation program creates.

      When specifying the directory:

      • Verify that the directory has the execute permission. This permission is required to run Terraform binaries under the installation directory.
      • Use an empty directory. Some installation assets, such as bootstrap X.509 certificates, have short expiration intervals, therefore you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OpenShift Container Platform version.

   2. At the prompts, provide the configuration details for your cloud:

      1. Optional: Select an SSH key to use to access your cluster machines.

         Note

         For production OpenShift Container Platform clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your ssh-agent process uses.

      2. Select openstack as the platform to target.
      3. Specify the Red Hat OpenStack Platform (RHOSP) external network name to use for installing the cluster.
      4. Specify the floating IP address to use for external access to the OpenShift API.
      5. Specify a RHOSP flavor with at least 16 GB RAM to use for control plane nodes and 8 GB RAM for compute nodes.
      6. Select the base domain to deploy the cluster to. All DNS records will be sub-domains of this base and will also include the cluster name.
      7. Enter a name for your cluster. The name must be 14 or fewer characters long.
2. Modify the install-config.yaml file. You can find more information about the available parameters in the "Installation configuration parameters" section.

3. Back up the install-config.yaml file so that you can use it to install multiple clusters.

   Important

   The install-config.yaml file is consumed during the installation process. If you want to reuse the file, you must back it up now.

Procedure

1. Change to the directory that contains the OpenShift Container Platform installation program and generate the Kubernetes manifests for the cluster:

   $ ./openshift-install create manifests --dir <installation_directory> 1

   1

   For <installation_directory>, specify the installation directory that contains the install-config.yaml file you created.

2. Remove the Kubernetes manifest files that define the control plane machines, compute machine sets, and control plane machine sets:

   $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

   Because you create and manage these resources yourself, you do not have to initialize them.

   • You can preserve the compute machine set files to create compute machines by using the machine API, but you must update references to them to match your environment.

3. Check that the mastersSchedulable parameter in the <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes manifest file is set to false. This setting prevents pods from being scheduled on the control plane machines:

   1. Open the <installation_directory>/manifests/cluster-scheduler-02-config.yml file.
   2. Locate the mastersSchedulable parameter and ensure that it is set to false.
   3. Save and exit the file.

4. To create the Ignition configuration files, run the following command from the directory that contains the installation program:

   $ ./openshift-install create ignition-configs --dir <installation_directory> 1

   1

   For <installation_directory>, specify the same installation directory.

   Ignition config files are created for the bootstrap, control plane, and compute nodes in the installation directory. The kubeadmin-password and kubeconfig files are created in the ./<installation_directory>/auth directory:

   .
   ├── auth
   │   ├── kubeadmin-password
   │   └── kubeconfig
   ├── bootstrap.ign
   ├── master.ign
   ├── metadata.json
   └── worker.ign

5. Export the metadata file’s infraID key as an environment variable:

   $ export INFRA_ID=$(jq -r .infraID metadata.json)

Procedure

1. Run the following Python script. The script modifies the bootstrap Ignition file to set the hostname and, if available, CA certificate file when it runs:

   import base64
   import json
   import os
   
   with open('bootstrap.ign', 'r') as f:
       ignition = json.load(f)
   
   files = ignition['storage'].get('files', [])
   
   infra_id = os.environ.get('INFRA_ID', 'openshift').encode()
   hostname_b64 = base64.standard_b64encode(infra_id + b'-bootstrap\n').decode().strip()
   files.append(
   {
       'path': '/etc/hostname',
       'mode': 420,
       'contents': {
           'source': 'data:text/plain;charset=utf-8;base64,' + hostname_b64
       }
   })
   
   ca_cert_path = os.environ.get('OS_CACERT', '')
   if ca_cert_path:
       with open(ca_cert_path, 'r') as f:
           ca_cert = f.read().encode()
           ca_cert_b64 = base64.standard_b64encode(ca_cert).decode().strip()
   
       files.append(
       {
           'path': '/opt/openshift/tls/cloud-ca-cert.pem',
           'mode': 420,
           'contents': {
               'source': 'data:text/plain;charset=utf-8;base64,' + ca_cert_b64
           }
       })
   
   ignition['storage']['files'] = files;
   
   with open('bootstrap.ign', 'w') as f:
       json.dump(ignition, f)

2. Using the RHOSP CLI, create an image that uses the bootstrap Ignition file:

   $ openstack image create --disk-format=raw --container-format=bare --file bootstrap.ign <image_name>

3. Get the image’s details:

   $ openstack image show <image_name>

   Make a note of the file value; it follows the pattern v2/images/<image_ID>/file.

   Note

   Verify that the image you created is active.

4. Retrieve the image service’s public address:

   $ openstack catalog show image

5. Combine the public address with the image file value and save the result as the storage location. The location follows the pattern <image_service_public_URL>/v2/images/<image_ID>/file.

6. Generate an auth token and save the token ID:

   $ openstack token issue -c id -f value

7. Insert the following content into a file called $INFRA_ID-bootstrap-ignition.json and edit the placeholders to match your own values:

   {
     "ignition": {
       "config": {
         "merge": [{
           "source": "<storage_url>", 1
           "httpHeaders": [{
             "name": "X-Auth-Token", 2
             "value": "<token_ID>" 3
           }]
         }]
       },
       "security": {
         "tls": {
           "certificateAuthorities": [{
             "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>" 4
           }]
         }
       },
       "version": "3.2.0"
     }
   }

   1

   Replace the value of ignition.config.merge.source with the bootstrap Ignition file storage URL.

   2

   Set name in httpHeaders to "X-Auth-Token".

   3

   Set value in httpHeaders to your token’s ID.

   4

   If the bootstrap Ignition file server uses a self-signed certificate, include the base64-encoded certificate.

8. Save the secondary Ignition config file.

Procedure

1. Optional: Add an external network value to the inventory.yaml playbook:

   Example external network value in the inventory.yaml Ansible Playbook

   ...
         # The public network providing connectivity to the cluster. If not
         # provided, the cluster external connectivity must be provided in another
         # way.
   
         # Required for os_api_fip, os_ingress_fip, os_bootstrap_fip.
         os_external_network: 'external'
   ...

   Important

   If you did not provide a value for os_external_network in the inventory.yaml file, you must ensure that VMs can access Glance and an external connection yourself.

2. Optional: Add external network and floating IP (FIP) address values to the inventory.yaml playbook:

   Example FIP values in the inventory.yaml Ansible Playbook

   ...
         # OpenShift API floating IP address. If this value is non-empty, the
         # corresponding floating IP will be attached to the Control Plane to
         # serve the OpenShift API.
         os_api_fip: '203.0.113.23'
   
         # OpenShift Ingress floating IP address. If this value is non-empty, the
         # corresponding floating IP will be attached to the worker nodes to serve
         # the applications.
         os_ingress_fip: '203.0.113.19'
   
         # If this value is non-empty, the corresponding floating IP will be
         # attached to the bootstrap machine. This is needed for collecting logs
         # in case of install failure.
         os_bootstrap_fip: '203.0.113.20'

   Important

   If you do not define values for os_api_fip and os_ingress_fip, you must perform postinstallation network configuration.

   If you do not define a value for os_bootstrap_fip, the installation program cannot download debugging information from failed installations.

   See "Enabling access to the environment" for more information.

3. On a command line, create security groups by running the security-groups.yaml playbook:

   $ ansible-playbook -i inventory.yaml security-groups.yaml

4. On a command line, update the network resources by running the update-network-resources.yaml playbook:

   $ ansible-playbook -i inventory.yaml update-network-resources.yaml 1

   1

   This playbook will add tags to the network, subnets, ports, and router. It also attaches floating IP addresses to the API and Ingress ports and sets the security groups for those ports.

5. Optional: If you want to control the default resolvers that Nova servers use, run the RHOSP CLI command:

   $ openstack subnet set --dns-nameserver <server_1> --dns-nameserver <server_2> "$INFRA_ID-nodes"

6. Optional: You can use the inventory.yaml file that you created to customize your installation. For example, you can deploy a cluster that uses bare metal machines.

Procedure

1. On a command line, change the working directory to the location of the playbooks.

2. On a command line, run the bootstrap.yaml playbook:

   $ ansible-playbook -i inventory.yaml bootstrap.yaml

3. After the bootstrap server is active, view the logs to verify that the Ignition files were received:

   $ openstack console log show "$INFRA_ID-bootstrap"

Procedure

1. On a command line, change the working directory to the location of the playbooks.
2. If the control plane Ignition config files aren’t already in your working directory, copy them into it.

3. On a command line, run the control-plane.yaml playbook:

   $ ansible-playbook -i inventory.yaml control-plane.yaml

4. Run the following command to monitor the bootstrapping process:

   $ openshift-install wait-for bootstrap-complete

   You will see messages that confirm that the control plane machines are running and have joined the cluster:

   INFO API v1.28.5 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   ...
   INFO It is now safe to remove the bootstrap resources

Procedure

1. Export the kubeadmin credentials:

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   For <installation_directory>, specify the path to the directory that you stored the installation files in.

2. Verify you can run oc commands successfully using the exported configuration:

   $ oc whoami

   Example output

   system:admin

Procedure

1. On a command line, change the working directory to the location of the playbooks.

2. On a command line, run the down-bootstrap.yaml playbook:

   $ ansible-playbook -i inventory.yaml down-bootstrap.yaml

Procedure

1. On a command line, change the working directory to the location of the playbooks.

2. On a command line, run the playbook:

   $ ansible-playbook -i inventory.yaml compute-nodes.yaml

Procedure

1. Confirm that the cluster recognizes the machines:

   $ oc get nodes

   Example output

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.28.5
   master-1  Ready     master  63m  v1.28.5
   master-2  Ready     master  64m  v1.28.5

   The output lists all of the machines that you created.

   Note

   The preceding output might not include the compute nodes, also known as worker nodes, until some CSRs are approved.

2. Review the pending CSRs and ensure that you see the client requests with the Pending or Approved status for each machine that you added to the cluster:

   $ oc get csr

   Example output

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   In this example, two machines are joining the cluster. You might see more approved CSRs in the list.

3. If the CSRs were not approved, after all of the pending CSRs for the machines you added are in Pending status, approve the CSRs for your cluster machines:

   Note

   Because the CSRs rotate automatically, approve your CSRs within an hour of adding the machines to the cluster. If you do not approve them within an hour, the certificates will rotate, and more than two certificates will be present for each node. You must approve all of these certificates. After the client CSR is approved, the Kubelet creates a secondary CSR for the serving certificate, which requires manual approval. Then, subsequent serving certificate renewal requests are automatically approved by the machine-approver if the Kubelet requests a new certificate with identical parameters.

   Note

   For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If a request is not approved, then the oc exec, oc rsh, and oc logs commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the Kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the CSR was submitted by the node-bootstrapper service account in the system:node or system:admin groups, and confirm the identity of the node.

   • To approve them individually, run the following command for each valid CSR:

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> is the name of a CSR from the list of current CSRs.

   • To approve all pending CSRs, run the following command:

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     Note

     Some Operators might not become available until some CSRs are approved.

4. Now that your client requests are approved, you must review the server requests for each machine that you added to the cluster:

   $ oc get csr

   Example output

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. If the remaining CSRs are not approved, and are in the Pending status, approve the CSRs for your cluster machines:

   • To approve them individually, run the following command for each valid CSR:

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> is the name of a CSR from the list of current CSRs.

   • To approve all pending CSRs, run the following command:

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. After all client and server CSRs have been approved, the machines have the Ready status. Verify this by running the following command:

   $ oc get nodes

   Example output

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.28.5
   master-1  Ready     master  73m  v1.28.5
   master-2  Ready     master  74m  v1.28.5
   worker-0  Ready     worker  11m  v1.28.5
   worker-1  Ready     worker  11m  v1.28.5

   Note

   It can take a few minutes after approval of the server CSRs for the machines to transition to the Ready status.

1. As an administrator in the RHOSP CLI, add the swiftoperator role to the account that will access Swift:

   $ openstack role add --user <user> --project <project> swiftoperator

Procedure

1. Create the clouds.yaml file:

   • If your RHOSP distribution includes the Horizon web UI, generate a clouds.yaml file in it.

     Important

     Remember to add a password to the auth field. You can also keep secrets in a separate file from clouds.yaml.

   • If your RHOSP distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about clouds.yaml, see Config files in the RHOSP documentation.

     clouds:
       shiftstack:
         auth:
           auth_url: http://10.10.14.42:5000/v3
           project_name: shiftstack
           username: <username>
           password: <password>
           user_domain_name: Default
           project_domain_name: Default
       dev-env:
         region_name: RegionOne
         auth:
           username: <username>
           password: <password>
           project_name: 'devonly'
           auth_url: 'https://10.10.14.22:5001/v2.0'

2. If your RHOSP installation uses self-signed certificate authority (CA) certificates for endpoint authentication:

   1. Copy the certificate authority file to your machine.

   2. Add the cacerts key to the clouds.yaml file. The value must be an absolute, non-root-accessible path to the CA certificate:

      clouds:
        shiftstack:
          ...
          cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"

      Tip

      After you run the installer with a custom CA certificate, you can update the certificate by editing the value of the ca-cert.pem key in the cloud-provider-config keymap. On a command line, run:

      $ oc edit configmap -n openshift-config cloud-provider-config

3. Place the clouds.yaml file in one of the following locations:

   1. The value of the OS_CLIENT_CONFIG_FILE environment variable
   2. The current directory
   3. A Unix-specific user configuration directory, for example ~/.config/openstack/clouds.yaml

   4. A Unix-specific site configuration directory, for example /etc/openstack/clouds.yaml

      The installation program searches for clouds.yaml in that order.

Procedure

1. If you have not already generated manifest files for your cluster, generate them by running the following command:

   $ openshift-install --dir <destination_directory> create manifests

2. In a text editor, open the cloud-provider configuration manifest file. For example:

   $ vi openshift/manifests/cloud-provider-config.yaml

3. Modify the options according to the CCM reference guide.

   Configuring Octavia for load balancing is a common case. For example:

   #...
   [LoadBalancer]
   lb-provider = "amphora" 1
   floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a" 2
   create-monitor = True 3
   monitor-delay = 10s 4
   monitor-timeout = 10s 5
   monitor-max-retries = 1 6
   #...

   1

   This property sets the Octavia provider that your load balancer uses. It accepts "ovn" or "amphora" as values. If you choose to use OVN, you must also set lb-method to SOURCE_IP_PORT.

   2

   This property is required if you want to use multiple external networks with your cluster. The cloud provider creates floating IP addresses on the network that is specified here.

   3

   This property controls whether the cloud provider creates health monitors for Octavia load balancers. Set the value to True to create health monitors. As of RHOSP 16.2, this feature is only available for the Amphora provider.

   4

   This property sets the frequency with which endpoints are monitored. The value must be in the time.ParseDuration() format. This property is required if the value of the create-monitor property is True.

   5

   This property sets the time that monitoring requests are open before timing out. The value must be in the time.ParseDuration() format. This property is required if the value of the create-monitor property is True.

   6

   This property defines how many successful monitoring requests are required before a load balancer is marked as online. The value must be an integer. This property is required if the value of the create-monitor property is True.

   Important

   Prior to saving your changes, verify that the file is structured correctly. Clusters might fail if properties are not placed in the appropriate section.

   Important

   You must set the value of the create-monitor property to True if you use services that have the value of the .spec.externalTrafficPolicy property set to Local. The OVN Octavia provider in RHOSP 16.2 does not support health monitors. Therefore, services that have ETP parameter values set to Local might not respond when the lb-provider value is set to "ovn".

4. Save the changes to the file and proceed with installation.

   Tip

   You can update your cloud provider configuration after you run the installer. On a command line, run:

   $ oc edit configmap -n openshift-config cloud-provider-config

   After you save your changes, your cluster will take some time to reconfigure itself. The process is complete if none of your nodes have a SchedulingDisabled status.

Procedure

1. Log in to the Red Hat Customer Portal’s Product Downloads page.

2. Under Version, select the most recent release of OpenShift Container Platform 4.15 for RHEL 8.

   Important

   The RHCOS images might not change with every release of OpenShift Container Platform. You must download images with the highest version that is less than or equal to the OpenShift Container Platform version that you install. Use the image versions that match your OpenShift Container Platform version if they are available.

3. Download the Red Hat Enterprise Linux CoreOS (RHCOS) - OpenStack Image (QCOW) image.

4. Decompress the image.

   Note

   You must decompress the image before the cluster can use it. The name of the downloaded file might not contain a compression extension, like .gz or .tgz. To find out if or how the file is compressed, in a command line, enter:

   $ file <name_of_downloaded_file>

5. Upload the image that you decompressed to a location that is accessible from the bastion server, like Glance. For example:

   $ openstack image create --file rhcos-44.81.202003110027-0-openstack.x86_64.qcow2 --disk-format qcow2 rhcos-${RHCOS_VERSION}

   Important

   Depending on your RHOSP environment, you might be able to upload the image in either .raw or .qcow2 formats. If you use Ceph, you must use the .raw format.

   Warning

   If the installation program finds multiple images with the same name, it chooses one of them at random. To avoid this behavior, create unique names for resources in RHOSP.

Procedure

1. Create the install-config.yaml file.

   1. Change to the directory that contains the installation program and run the following command:

      $ ./openshift-install create install-config --dir <installation_directory> 1

      1

      For <installation_directory>, specify the directory name to store the files that the installation program creates.

      When specifying the directory:

      • Verify that the directory has the execute permission. This permission is required to run Terraform binaries under the installation directory.
      • Use an empty directory. Some installation assets, such as bootstrap X.509 certificates, have short expiration intervals, therefore you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OpenShift Container Platform version.

   2. At the prompts, provide the configuration details for your cloud:

      1. Optional: Select an SSH key to use to access your cluster machines.

         Note

         For production OpenShift Container Platform clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your ssh-agent process uses.

      2. Select openstack as the platform to target.
      3. Specify the Red Hat OpenStack Platform (RHOSP) external network name to use for installing the cluster.
      4. Specify the floating IP address to use for external access to the OpenShift API.
      5. Specify a RHOSP flavor with at least 16 GB RAM to use for control plane nodes and 8 GB RAM for compute nodes.
      6. Select the base domain to deploy the cluster to. All DNS records will be sub-domains of this base and will also include the cluster name.
      7. Enter a name for your cluster. The name must be 14 or fewer characters long.

2. In the install-config.yaml file, set the value of platform.openstack.clusterOSImage to the image location or name. For example:

   platform:
     openstack:
         clusterOSImage: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d

3. Edit the install-config.yaml file to give the additional information that is required for an installation in a restricted network.

   1. Update the pullSecret value to contain the authentication information for your registry:

      pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'

      For <mirror_host_name>, specify the registry domain name that you specified in the certificate for your mirror registry, and for <credentials>, specify the base64-encoded user name and password for your mirror registry.

   2. Add the additionalTrustBundle parameter and value.

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----

      The value must be the contents of the certificate file that you used for your mirror registry. The certificate file can be an existing, trusted certificate authority, or the self-signed certificate that you generated for the mirror registry.

   3. Add the image content resources, which resemble the following YAML excerpt:

      imageContentSources:
      - mirrors:
        - <mirror_host_name>:5000/<repo_name>/release
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - <mirror_host_name>:5000/<repo_name>/release
        source: registry.redhat.io/ocp/release

      For these values, use the imageContentSources that you recorded during mirror registry creation.

   4. Optional: Set the publishing strategy to Internal:

      publish: Internal

      By setting this option, you create an internal Ingress Controller and a private load balancer.

4. Make any other modifications to the install-config.yaml file that you require.

   For more information about the parameters, see "Installation configuration parameters".

5. Back up the install-config.yaml file so that you can use it to install multiple clusters.

   Important

   The install-config.yaml file is consumed during the installation process. If you want to reuse the file, you must back it up now.

Procedure

1. If you do not have an existing SSH key pair on your local machine to use for authentication onto your cluster nodes, create one. For example, on a computer that uses a Linux operating system, run the following command:

   $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1

   1

   Specify the path and file name, such as ~/.ssh/id_ed25519, of the new SSH key. If you have an existing key pair, ensure your public key is in the your ~/.ssh directory.

   Note

   If you plan to install an OpenShift Container Platform cluster that uses the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures, do not create a key that uses the ed25519 algorithm. Instead, create a key that uses the rsa or ecdsa algorithm.

2. View the public SSH key:

   $ cat <path>/<file_name>.pub

   For example, run the following to view the ~/.ssh/id_ed25519.pub public key:

   $ cat ~/.ssh/id_ed25519.pub

3. Add the SSH private key identity to the SSH agent for your local user, if it has not already been added. SSH agent management of the key is required for password-less SSH authentication onto your cluster nodes, or if you want to use the ./openshift-install gather command.

   Note

   On some distributions, default SSH private key identities such as ~/.ssh/id_rsa and ~/.ssh/id_dsa are managed automatically.

   1. If the ssh-agent process is not already running for your local user, start it as a background task:

      $ eval "$(ssh-agent -s)"

      Example output

      Agent pid 31874

      Note

      If your cluster is in FIPS mode, only use FIPS-compliant algorithms to generate the SSH key. The key must be either RSA or ECDSA.

4. Add your SSH private key to the ssh-agent:

   $ ssh-add <path>/<file_name> 1

   1

   Specify the path and file name for your SSH private key, such as ~/.ssh/id_ed25519

   Example output

   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

Procedure

1. In the cluster environment, export the administrator’s kubeconfig file:

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   For <installation_directory>, specify the path to the directory that you stored the installation files in.

   The kubeconfig file contains information about the cluster that is used by the CLI to connect a client to the correct cluster and API server.

2. View the control plane and compute machines created after a deployment:

   $ oc get nodes

3. View your cluster’s version:

   $ oc get clusterversion

4. View your Operators' status:

   $ oc get clusteroperator

5. View all running pods in the cluster:

   $ oc get pods -A

Procedure

1. Export the kubeadmin credentials:

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   For <installation_directory>, specify the path to the directory that you stored the installation files in.

2. Verify you can run oc commands successfully using the exported configuration:

   $ oc whoami

   Example output

   system:admin

Procedure

1. Create a Nova flavor for the control plane with at least 10 GB of ephemeral disk by running the following command, replacing the values for --ram, --disk, and <flavor_name> based on your environment:

   $ openstack flavor create --<ram 16384> --<disk 0> --ephemeral 10 --vcpus 4 <flavor_name>

2. Deploy a cluster with root volumes for the control plane; for example:

   Example YAML file

   # ...
   controlPlane:
     name: master
     platform:
       openstack:
         type: ${CONTROL_PLANE_FLAVOR}
         rootVolume:
           size: 25
           types:
           - ${CINDER_TYPE}
     replicas: 3
   # ...

3. Deploy the cluster you created by running the following command:

   $ openshift-install create cluster --dir <installation_directory> 1

   1

   For <installation_directory>, specify the location of the customized ./install-config.yaml file that you previously created.

4. Verify that the cluster you deployed is healthy before proceeding to the next step by running the following command:

   $ oc wait clusteroperators --all --for=condition=Progressing=false 1

   1

   Ensures that the cluster operators are finished progressing and that the cluster is not deploying or updating.

5. Edit the ControlPlaneMachineSet (CPMS) to add the additional block ephemeral device that is used by etcd by running the following command:

   $ oc patch ControlPlaneMachineSet/cluster -n openshift-machine-api --type json -p ' 1
   [
       {
         "op": "add",
         "path": "/spec/template/machines_v1beta1_machine_openshift_io/spec/providerSpec/value/additionalBlockDevices", 2
         "value": [
           {
             "name": "etcd",
             "sizeGiB": 10,
             "storage": {
               "type": "Local" 3
             }
           }
         ]
       }
     ]
   '

   1

   Applies the JSON patch to the ControlPlaneMachineSet custom resource (CR).

   2

   Specifies the path where the additionalBlockDevices are added.

   3

   Adds the etcd devices with at least local storage of 10 GB to the cluster. You can specify values greater than 10 GB as long as the etcd device fits the Nova flavor. For example, if the Nova flavor has 15 GB, you can create the etcd device with 12 GB.

6. Verify that the control plane machines are healthy by using the following steps:

   1. Wait for the control plane machine set update to finish by running the following command:

      $ oc wait --timeout=90m --for=condition=Progressing=false controlplanemachineset.machine.openshift.io -n openshift-machine-api cluster

   2. Verify that the 3 control plane machine sets are updated by running the following command:

      $ oc wait --timeout=90m --for=jsonpath='{.status.updatedReplicas}'=3 controlplanemachineset.machine.openshift.io -n openshift-machine-api cluster

   3. Verify that the 3 control plane machine sets are healthy by running the following command:

      $ oc wait --timeout=90m --for=jsonpath='{.status.replicas}'=3 controlplanemachineset.machine.openshift.io -n openshift-machine-api cluster

   4. Verify that the ClusterOperators are not progressing in the cluster by running the following command:

      $ oc wait clusteroperators --timeout=30m --all --for=condition=Progressing=false

   5. Verify that each of the 3 control plane machines has the additional block device you previously created by running the following script:

   $ cp_machines=$(oc get machines -n openshift-machine-api --selector='machine.openshift.io/cluster-api-machine-role=master' --no-headers -o custom-columns=NAME:.metadata.name) 1
   
   
   if [[ $(echo "${cp_machines}" | wc -l) -ne 3 ]]; then
     exit 1
   fi 2
   
   
   for machine in ${cp_machines}; do
     if ! oc get machine -n openshift-machine-api "${machine}" -o jsonpath='{.spec.providerSpec.value.additionalBlockDevices}' | grep -q 'etcd'; then
   	exit 1
     fi 3
   done

   1

   Retrieves the control plane machines running in the cluster.

   2

   Iterates over machines which have an additionalBlockDevices entry with the name etcd.

   3

   Outputs the name of every control plane machine which has an additionalBlockDevice named etcd.

7. Create a file named 98-var-lib-etcd.yaml by using the following YAML file:

   Warning

   This procedure is for testing etcd on a local disk and should not be used on a production cluster. In certain cases, complete loss of the control plane can occur. For more information, see "Overview of backup and restore operation" under "Backup and restore".

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.4.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Mount local-etcd to /var/lib/etcd
   
             [Mount]
             What=/dev/disk/by-label/local-etcd 1
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount
         - contents: |
             [Unit]
             Description=Create local-etcd filesystem
             DefaultDependencies=no
             After=local-fs-pre.target
             ConditionPathIsSymbolicLink=!/dev/disk/by-label/local-etcd 2
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/bin/bash -c "[ -L /dev/disk/by-label/ephemeral0 ] || ( >&2 echo Ephemeral disk does not exist; /usr/bin/false )"
             ExecStart=/usr/sbin/mkfs.xfs -f -L local-etcd /dev/disk/by-label/ephemeral0 3
   
             [Install]
             RequiredBy=dev-disk-by\x2dlabel-local\x2detcd.device
           enabled: true
           name: create-local-etcd.service
         - contents: |
             [Unit]
             Description=Migrate existing data to local etcd
             After=var-lib-etcd.mount
             Before=crio.service 4
   
             Requisite=var-lib-etcd.mount
             ConditionPathExists=!/var/lib/etcd/member
             ConditionPathIsDirectory=/sysroot/ostree/deploy/rhcos/var/lib/etcd/member 5
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
   
             ExecStart=/bin/bash -c "if [ -d /var/lib/etcd/member.migrate ]; then rm -rf /var/lib/etcd/member.migrate; fi" 6
   
             ExecStart=/usr/bin/cp -aZ /sysroot/ostree/deploy/rhcos/var/lib/etcd/member/ /var/lib/etcd/member.migrate
             ExecStart=/usr/bin/mv /var/lib/etcd/member.migrate /var/lib/etcd/member 7
   
             [Install]
             RequiredBy=var-lib-etcd.mount
           enabled: true
           name: migrate-to-local-etcd.service
         - contents: |
             [Unit]
             Description=Relabel /var/lib/etcd
   
             After=migrate-to-local-etcd.service
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
   
             ExecCondition=/bin/bash -c "[ -n \"$(restorecon -nv /var/lib/etcd)\" ]" 8
   
             ExecStart=/usr/sbin/restorecon -R /var/lib/etcd
   
             [Install]
             RequiredBy=var-lib-etcd.mount
           enabled: true
           name: relabel-var-lib-etcd.service

   1

   The etcd database must be mounted by the device, not a label, to ensure that systemd generates the device dependency used in this config to trigger filesystem creation.

   2

   Do not run if the file system dev/disk/by-label/local-etcd already exists.

   3

   Fails with an alert message if /dev/disk/by-label/ephemeral0 doesn’t exist.

   4

   Migrates existing data to local etcd database. This config does so after /var/lib/etcd is mounted, but before CRI-O starts so etcd is not running yet.

   5

   Requires that etcd is mounted and does not contain a member directory, but the ostree does.

   6

   Cleans up any previous migration state.

   7

   Copies and moves in separate steps to ensure atomic creation of a complete member directory.

   8

   Performs a quick check of the mount point directory before performing a full recursive relabel. If restorecon in the file path /var/lib/etcd cannot rename the directory, the recursive rename is not performed.

8. Create the new MachineConfig object by running the following command:

   $ oc create -f 98-var-lib-etcd.yaml

   Note

   Moving the etcd database onto the local disk of each control plane machine takes time.

9. Verify that the etcd databases has been transferred to the local disk of each control plane by running the following commands:

   1. Verify that the cluster is still updating by running the following command:

      $ oc wait --timeout=45m --for=condition=Updating=false machineconfigpool/master

   2. Verify that the cluster is ready by running the following command:

      $ oc wait node --selector='node-role.kubernetes.io/master' --for condition=Ready --timeout=30s

   3. Verify that the cluster Operators are running in the cluster by running the following command:

      $ oc wait clusteroperators --timeout=30m --all --for=condition=Progressing=false

Procedure

1. From the directory that contains the installation program on the computer that you used to install the cluster, run the following command:

   $ ./openshift-install destroy cluster \
   --dir <installation_directory> --log-level info 1 2

   1

   For <installation_directory>, specify the path to the directory that you stored the installation files in.

   2

   To view different details, specify warn, debug, or error instead of info.

   Note

   You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster.

2. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Procedure

1. On a command line, add the repositories:

   1. Register with Red Hat Subscription Manager:

      $ sudo subscription-manager register # If not done already

   2. Pull the latest subscription data:

      $ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already

   3. Disable the current repositories:

      $ sudo subscription-manager repos --disable=* # If not done already

   4. Add the required repositories:

      $ sudo subscription-manager repos \
        --enable=rhel-8-for-x86_64-baseos-rpms \
        --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
        --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
        --enable=rhel-8-for-x86_64-appstream-rpms

2. Install the modules:

   $ sudo yum install python3-openstackclient ansible python3-openstacksdk

3. Ensure that the python command points to python3:

   $ sudo alternatives --set python /usr/bin/python3

Procedure

1. On a command line, run the playbooks that you downloaded:

   $ ansible-playbook -i inventory.yaml  \
   	down-bootstrap.yaml      \
   	down-control-plane.yaml  \
   	down-compute-nodes.yaml  \
   	down-load-balancers.yaml \
   	down-network.yaml        \
   	down-security-groups.yaml

2. Remove any DNS record changes you made for the OpenShift Container Platform installation.