Search

Chapter 6. Configuring and deploying the overcloud with director Operator

download PDF

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.

Tip

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.

Procedure

  1. 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 the fence-agents-kubevirt package.
    3
    Set to the ConfigMap object that contains the Git authentication credentials, by default git-secret.
    4
    The ConfigMap object that contains your custom environment files, by default heat-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 default tripleo-tarball-config.
  2. Optional: To change the location of the container images the OpenStackConfigGenerator CR uses to create the ephemeral heat service, add the following configuration to your openstack-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.
  3. 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.

  4. Save the openstack-config-generator.yaml file.
  5. Create the Ansible config generator:

    $ oc create -f openstack-config-generator.yaml -n openstack
  6. 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

  1. Open an RSH connection to the OpenStackClient pod:

    $ oc rsh -n openstack openstackclient
  2. Change to the cloud-admin home directory:

    $ cd /home/cloud-admin
  3. 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 }}"
    1
    Task that registers the node.
    2
    Task that disables any auto-enabled repositories.
    3
    Task that enables only the repositories relevant to the Controller node. The repositories are listed with the repos variable.
  4. 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.

Tip

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

  1. Retrieve the hash/digest of the latest OpenStackConfigVersion 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
  2. 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 playbooks hash/digest retrieved in step 1, for example, n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h....
  3. Save the openstack-deployment.yaml file.
  4. 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 the ansible.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 prefix generate-config has started.

Procedure

  1. Open a Remote Shell (RSH) connection to the OpenStackConfigGenerator pod:

    $ oc rsh $(oc get pod -o name -l job-name=generate-config-default)
  2. 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.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.