Chapter 1. Introduction to the Red Hat OpenStack Platform director Operator

OpenShift Container Platform (OCP) uses a modular system of operators to extend the functions of your OCP cluster. The Red Hat OpenStack Platform (RHOSP) director Operator adds the ability to install and run a RHOSP cloud within OCP. This operator manages a set of Custom Resource Definitions (CRDs) for managing and deploying the infrastructure and configuration of RHOSP nodes. The basic architecture of an operator-deployed RHOSP cloud includes the following features:

Virtualized control plane
The director Operator creates a set of virtual machines in OpenShift Virtualization to act as Controller nodes.
Bare metal machine provisioning
The director Operator uses OCP bare metal machine management to provision Compute nodes in an operator-deployed RHOSP cloud.
Networking
The director Operator configures the underlying networks for RHOSP services.
Heat and Ansible-based configuration
The director Operator stores custom Heat configuration in OCP and uses the config-download functionality in director to convert the configuration into Ansible playbooks. If you change the stored heat configuration, the director Operator automatically regenerates the Ansible playbooks.
CLI client
The director Operator creates a pod for users to run RHOSP CLI commands and interact with their RHOSP cloud.

Additional resources

1.1. Prerequisites for the director Operator

Before you install the Red Hat OpenStack Platform (RHOSP) director Operator, you must complete the following prerequisite tasks.

  • Install an Openshift Container Platform (OCP) 4.6 or later cluster that contains a baremetal cluster operator that has been enabled and a provisioning network.

    Note

    OCP clusters that you install with the installer-provisioned infrastructure (IPI) or assisted installation (AI) use the baremetal platform type and have the baremetal cluster Operator enabled. OCP clusters that you install with user-provisioned infrastructure (UPI) use the none platform type and might have the baremetal cluster Operator disabled.

    To check if the baremetal cluster Operator is enabled, navigate to Administration > Cluster Settings > ClusterOperators > baremetal, scroll to the Conditions section, and view the Disabled status.

    To check the platform type of the OCP cluster, navigate to Administration > Global Configuration > Infrastructure, switch to YAML view, scroll to the Conditions section, and view the status.platformStatus value.

  • Install the following prerequisite Operators from OperatorHub on your OCP cluster:

    • OpenShift Virtualization 2.6 or later
    • SR-IOV Network Operator
  • Configure a remote Git repository for the director Operator to store the generated configuration for your overcloud.
  • Create the following persistent volumes to fulfil the following persistent volume claims that the director Operator creates:

    • 4G for openstackclient-cloud-admin
    • 1G for openstackclient-hosts
    • 50G for the base image that the director Operator clones for each Controller virtual machine
    • A minimum of 50G for each Controller virtual machine

Additional resources

1.2. Installing the director Operator

To install the director Operator, you must create a namespace for the Operator and create the following three resources within the namespace:

  • A CatalogSource, which identifies the index image to use for the director Operator catalog.
  • A Subscription, which tracks changes in the director Operator catalog.
  • An OperatorGroup, which defines the Operator group for the director Operator and restricts the director Operator to a target namespace.

Prerequisites

  • Ensure your OpenShift Container Platform cluster is operational.
  • Install the following prerequisite Operators from OperatorHub:

    • OpenShift Virtualization 2.6 or later
    • SR-IOV Network Operator
  • Ensure that you have installed the oc command line tool on your workstation.

Procedure

  1. Create the openstack namespace:

    $ oc new-project openstack
  2. Create a file named osp-director-operator.yaml and include the following YAML content that configures the three resources to install the director Operator:

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: osp-director-operator-index
      namespace: openstack
    spec:
      sourceType: grpc
      image: quay.io/openstack-k8s-operators/osp-director-operator-index:1.0.0-1
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: "osp-director-operator-group"
      namespace: openstack
    spec:
      targetNamespaces:
      - openstack
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: osp-director-operator-subscription
      namespace: openstack
    spec:
      config:
        env:
        - name: WATCH_NAMESPACE
          value: openstack,openshift-machine-api,openshift-sriov-network-operator
      source: osp-director-operator-index
      sourceNamespace: openstack
      name: osp-director-operator
  3. Create the three new resources within the openstack namespace:

    $ oc create -f osp-director-operator.yaml

Verification

  1. Confirm that you have successfully installed the director Operator:

    $ oc get operators
    NAME                                     AGE
    osp-director-operator.openstack          5m

1.3. Custom resource definitions for the director Operator

The director Operator includes a set of custom resource definitions (CRDs) that you can use to manage overcloud resources. There are two types of CRDs: hardware provisioning and software configuration.

Hardware Provisioning CRDs

openstackbaremetalsets
Creates sets of bare metal hosts for a specific overcloud role, such as Compute and Ceph Storage.
openstackcontrolplanes
Creates the overcloud control plane and manages associated openstackvmsets.
openstackipsets
Defines a set of IP addresses for a network and role. OpenShift Container Platform (OCP) uses this CRD to manage IP addresses.
openstacknets
Creates networks to assign IP addresses to the openstackvmset and openstackbaremetalset resources.
openstackprovisionservers
Serves custom images for bare metal provisioning.
openstackvmsets
Creates sets of virtual machines for a specific overcloud role, such as Controller, Database, and Networker.

Software Configuration CRDs

openstackplaybookgenerators
Creates Ansible playbooks for deployment and regenerates the playbooks when you scale the overcloud or make changes to custom ConfigMaps.
openstackclients
Creates a pod for you to run deployment and management commands.

Viewing the director Operator CRDs

  • View a list of these CRDs with the oc get crd command:

    $ oc get crd | grep "^openstack"
  • View the definition for a specific CRD with the oc describe crd command:

    $ oc describe crd openstackbaremetalset
    Name:         openstackbaremetalsets.osp-director.openstack.org
    Namespace:
    Labels:       operators.coreos.com/osp-director-operator.openstack=
    Annotations:  cert-manager.io/inject-ca-from: $(CERTIFICATE_NAMESPACE)/$(CERTIFICATE_NAME)
                  controller-gen.kubebuilder.io/version: v0.3.0
    API Version:  apiextensions.k8s.io/v1
    Kind:         CustomResourceDefinition
    ...

CRD naming conventions

Each CRD contains multiple names in the spec.names section. Use these names depending on the context of your actions:

  • Use kind when you create and interact with resource manifests:

    apiVersion: osp-director.openstack.org/v1beta1
    kind: OpenStackBaremetalSet
    ....

    The kind name in the resource manifest correlates to the kind name in the respective CRD.

  • Use plural when you interact with multiple resources:

    $ oc get openstackbaremetalsets
  • Use singular when you interact with a single resource:

    $ oc describe openstackbaremetalset/compute
  • Use shortName for any CLI interactions:

    $ oc get osbmset

1.4. Workflow for overcloud deployment with the director Operator

After you have installed the Red Hat OpenStack Platform director Operator, you can use the resources specific to the director Operator to provision your overcloud infrastructure, generate your overcloud configuration, and create an overcloud.

The following workflow outlines the general process for creating an overcloud:

  1. Create the overcloud networks, including the control plane and any isolated networks.
  2. Create ConfigMaps to store any custom heat templates and environment files for your overcloud.
  3. Create a control plane, which includes three virtual machines for Controller nodes and a pod to perform client operations.
  4. Create bare metal Compute nodes.
  5. Create a generator to render Ansible playbooks for overcloud configuration.
  6. Apply the Ansible playbook configuration to your overcloud nodes.