Chapter 6. Configuring and deploying the overcloud with director Operator
You can configure your overcloud nodes after you have provisioned virtual and bare-metal nodes for your overcloud. You must create an OpenStackConfigGenerator
resource to generate your Ansible playbooks, register your nodes to either the Red Hat Customer Portal or Red Hat Satellite, and then create an OpenStackDeploy
resource to apply the configuration to your nodes.
6.1. Creating Ansible playbooks for overcloud configuration with the OpenStackConfigGenerator CRD
After you provision the overcloud infrastructure, you must create a set of Ansible playbooks to configure Red Hat OpenStack Platform (RHOSP) on the overcloud nodes. You use the OpenStackConfigGenerator
custom resource definition (CRD) to create these playbooks. The OpenStackConfigGenerator
CRD uses the RHOSP director config-download
feature to convert heat configuration to playbooks.
Use the following commands to view the OpenStackConfigGenerator
CRD definition and specification schema:
$ oc describe crd openstackconfiggenerator $ oc explain openstackconfiggenerator.spec
Prerequisites
-
You have created a control plane with the`
OpenStackControlPlane
CRD. -
You have created Compute nodes with the`
OpenStackBarementalSets
CRD. -
You have created a
ConfigMap
object that contains your custom heat templates. -
You have created a
ConfigMap
object that contains your custom environment files. -
You have manually installed the
fence-agents-kubevirt
package on the Controller VMs.
Procedure
Create a file named
openstack-config-generator.yaml
on your workstation. Include the resource specification to generate the Ansible playbooks. The following example defines a specification to generate the playbooks:apiVersion: osp-director.openstack.org/v1beta1 kind: OpenStackConfigGenerator metadata: name: default 1 namespace: openstack spec: enableFencing: true 2 gitSecret: git-secret 3 imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:17.1 heatEnvConfigMap: heat-env-config 4 # List of heat environment files to include from tripleo-heat-templates/environments heatEnvs: 5 - ssl/tls-endpoints-public-dns.yaml - ssl/enable-tls.yaml tarballConfigMap: tripleo-tarball-config 6
- 1
- The name of the config generator, which is
default
by default. - 2
- Set to
true
to enable the automatic creation of required heat environment files to enable fencing. Production RHOSP environments must have fencing enabled. Virtual machines running Pacemaker require thefence-agents-kubevirt
package. - 3
- Set to the
ConfigMap
object that contains the Git authentication credentials, by defaultgit-secret
. - 4
- The
ConfigMap
object that contains your custom environment files, by defaultheat-env-config
. - 5
- A list of the default heat environment files, provided by TripleO in the
tripleo-heat-templates/environments
directory, to use to generate the playbooks. - 6
- The
ConfigMap
object that contains the tarball with your custom heat templates, by defaulttripleo-tarball-config
.
Optional: To change the location of the container images the
OpenStackConfigGenerator
CR uses to create the ephemeral heat service, add the following configuration to youropenstack-config-generator.yaml
file:spec: ... ephemeralHeatSettings: heatAPIImageURL: <heat_api_image_location> heatEngineImageURL: <heat_engine_image_location> mariadbImageURL: <mariadb_image_location> rabbitImageURL: <rabbitmq_image_location>
-
Replace
<heat_api_image_location>
with the path to the directory where you host your heat API image,openstack-heat-api
. -
Replace
<heat_engine_image_location>
with the path to the directory where you host your heat engine image,openstack-heat-engine
. -
Replace
<mariadb_image_location>
with the path to the directory where you host your MariaDB image,openstack-mariadb
. -
Replace
<rabbitmq_image_location>
with the path to the directory where you host your RabbitMQ image,openstack-rabbitmq
.
-
Replace
Optional: Customize the ephemeral heat instance to override default heat parameter values. For example, include the following configuration to change the default
max_template_size
:spec: ... ephemeralHeatSettings: ... heatOverride: customServiceConfig: | [DEFAULT] max_template_size=1048576
Optional: To create the Ansible playbooks for configuration generation in debug mode, add the following configuration to your
openstack-config-generator.yaml
file:spec: ... interactive: true
For more information on debugging an
OpenStackConfigGenerator
pod in interactive mode, see Debugging configuration generation.-
Save the
openstack-config-generator.yaml
file. Create the Ansible config generator:
$ oc create -f openstack-config-generator.yaml -n openstack
Verify that the resource for the config generator is created:
$ oc get openstackconfiggenerator/default -n openstack
6.2. Registering the operating system of your overcloud
Before director Operator (OSPdO) configures the overcloud nodes, you must register the operating system of all nodes to either the Red Hat Customer Portal or Red Hat Satellite Server, and enable repositories for your nodes.
As part of the OpenStackControlPlane
CR, OSPdO creates an OpenStackClient
pod that you access through a Remote Shell (RSH) to run Red Hat OpenStack Platform (RHOSP) commands. This pod also contains an Ansible inventory script named /home/cloud-admin/ctlplane-ansible-inventory
.
To register your nodes, you can use the redhat_subscription
Ansible module with the inventory script from the OpenStackClient pod.
Procedure
Open an RSH connection to the
OpenStackClient
pod:$ oc rsh -n openstack openstackclient
Change to the
cloud-admin
home directory:$ cd /home/cloud-admin
Create a playbook that uses the
redhat_subscription
modules to register your nodes. For example, the following playbook registers Controller nodes:--- - name: Register Controller nodes hosts: Controller become: yes vars: repos: - rhel-9-for-x86_64-baseos-eus-rpms - rhel-9-for-x86_64-appstream-eus-rpms - rhel-9-for-x86_64-highavailability-eus-rpms - openstack-17.1-for-rhel-9-x86_64-rpms - fast-datapath-for-rhel-9-x86_64-rpms - rhceph-6-tools-for-rhel-9-x86_64-rpms tasks: - name: Register system 1 redhat_subscription: username: myusername password: p@55w0rd! org_id: 1234567 release: 9.2 pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd - name: Disable all repos 2 command: "subscription-manager repos --disable *" - name: Enable Controller node repos 3 command: "subscription-manager repos --enable {{ item }}" with_items: "{{ repos }}"
Register the overcloud nodes to the required repositories:
$ ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml
6.3. Applying overcloud configuration with director Operator
You can configure the overcloud with director Operator (OSPdO) only after you have created your control plane, provisioned your bare metal Compute nodes, and generated the Ansible playbooks to configure software on each node. When you create an OpenStackDeploy
custom resource (CR), OSPdO creates a job that runs the Ansible playbooks to configure the overcloud.
Use the following commands to view the OpenStackDeploy
CRD definition and specification schema:
$ oc describe crd openstackdeploy $ oc explain openstackdeploy.spec
Prerequisites
-
You have created a control plane with the
OpenStackControlPlane
CRD. -
You have created Compute nodes with the
OpenStackBarementalSets
CRD. -
You have used the
OpenStackConfigGenerator
CRD to create the Ansible playbook configuration for your overcloud.
Procedure
Retrieve the
hash/digest
of the latestOpenStackConfigVersion
object, which represents the Ansible playbooks that should be used to configure the overcloud:$ oc get -n openstack --sort-by {.metadata.creationTimestamp} openstackconfigversion -o json
Create a file named
openstack-deployment.yaml
on your workstation and include the resource specification to the Ansible playbooks:apiVersion: osp-director.openstack.org/v1beta1 kind: OpenStackDeploy metadata: name: default spec: configVersion: <config_version> configGenerator: default
-
Replace
<config_version>
with the Ansible playbookshash/digest
retrieved in step 1, for example,n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
.
-
Replace
-
Save the
openstack-deployment.yaml
file. Create the
OpenStackDeploy
resource:$ oc create -f openstack-deployment.yaml -n openstack
As the deployment runs, it creates a Kubernetes job to execute the Ansible playbooks. You can view the logs of the job to watch the Ansible playbooks running:
$ oc logs -f jobs/deploy-openstack-default
You can also manually access the executed Ansible playbooks by logging into the
openstackclient
pod. You can find the ansible playbooks and theansible.log
file for the current deployment in/home/cloud-admin/work/directory
.
6.4. Debugging configuration generation
To debug configuration generation operations, you can set the OpenStackConfigGenerator
CR to use interactive mode. In interactive mode, the OpenStackConfigGenerator
CR creates the environment to start rendering the playbooks, but does not automatically render the playbooks.
Prerequisites
Your
OpenStackConfigGenerator
CR was created in interactive mode:apiVersion: osp-director.openstack.org/v1beta1 kind: OpenStackConfigGenerator metadata: name: default namespace: openstack spec: … interactive: true
-
The
OpenStackConfigGenerator
pod with the prefixgenerate-config
has started.
Procedure
Open a Remote Shell (RSH) connection to the
OpenStackConfigGenerator
pod:$ oc rsh $(oc get pod -o name -l job-name=generate-config-default)
Inspect the files and playbook rendering:
$ ls -la /home/cloud-admin/ ... config 1 config-custom 2 config-passwords 3 create-playbooks.sh 4 process-heat-environment.py 5 tht-tars 6
- 1
- Directory that stores the files auto-rendered by OSPdO.
- 2
- Directory that stores the environment files specified with the
heatEnvConfigMap
option. - 3
- Directory that stores the overcloud service passwords created by OSPdO.
- 4
- Script that renders the Ansible playbooks.
- 5
- Internal script used by
create-playbooks
to replicate the undocumented heat client merging of map parameters. - 6
- Directory that stores the tarball specified with the
tarballConfigMap
option.