Procedure

1. Create the openstack namespace:

   $ oc new-project openstack

2. Obtain the latest osp-director-operator-bundle image from https://catalog.redhat.com/software/containers/search.
3. Download the Operator Package Manager (opm) tool from https://console.redhat.com/openshift/downloads.

4. Use the opm tool to create an index image:

   $ BUNDLE_IMG="registry.redhat.io/rhosp-rhel8/osp-director-operator-bundle@sha256:c19099ac3340d364307a43e0ae2be949a588fefe8fcb17663049342e7587f055"
   $ INDEX_IMG="quay.io/<account>/osp-director-operator-index:x.y.z-a"
   $ opm index add --bundles ${BUNDLE_IMG} --tag ${INDEX_IMG} -u podman --pull-tool podman

5. Push the index image to your registry:

   $ podman push ${INDEX_IMG}

6. 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/<account>/osp-director-operator-index:x.y.z-a 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

   1

   For information about how to apply the Quay authentication so that the Operator deployment can pull the image, see Accessing images for Operators from private registries.

7. Create the three new resources within the openstack namespace:

   $ oc apply -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. Create the overcloud networks using the openstacknetconfig CRD, 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 an openstackconfiggenerator to render Ansible playbooks for overcloud configuration.
6. Apply the Ansible playbook configuration to your overcloud nodes using openstackdeploy.

Procedure

1. The default QCOW2 image that you have downloaded from access.redhat.com does not use biosdev predictable network interface names. Modify the image with virt-customize to use biosdev predictable network interface names:

   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(kernelopts=.*\)net.ifnames=0 \(.*\)/\1\2/" /boot/grub2/grubenv'
   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net.ifnames=0 \(.*\)/\1\2/" /etc/default/grub' --truncate /etc/machine-id

2. Upload the image to OpenShift Virtualization with virtctl:

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • Replace <datavolume_name> with the name of the data volume, for example, openstack-base-img.
   • Replace <size> with the size of the data volume required for your environment, for example, 500Gi. The minimum size is 500GB.

   • Replace <storage_class> with the required storage class from your cluster. Use the following command to retrieve the available storage classes:

     $ oc get storageclass

   • Replace <access_mode> with the access mode for the PVC. The default value is ReadWriteOnce.

3. When you create the OpenStackControlPlane resource and individual OpenStackVmSet resources, set the baseImageVolumeName parameter to the data volume name:

   ...
   spec:
     ...
     baseImageVolumeName: openstack-base-img
   ...

Procedure

1. Create the Secret resource:

   $ oc create secret generic git-secret -n openstack --from-file=git_ssh_identity=<path_to_private_SSH_key> --from-literal=git_url=<git_server_URL>

   The git-secret Secret resource contains two key-value pairs:

   git_ssh_identity

   The private key to access the Git repository. The --from-file option stores the content of the private SSH key file.

   git_url

   The SSH URL of the git repository to store the configuration. The --from-literal option stores the URL that you enter for this key.

Verification

1. View the Secret resource:

   $ oc get secret/git-secret -n openstack

Procedure

1. Convert your chosen password to a base64 value:

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   Note

   The -n option removes the trailing newline from the echo output.

2. Create a file named openstack-userpassword.yaml on your workstation. Include the following resource specification for the Secret in the file:

   apiVersion: v1
   kind: Secret
   metadata:
     name: userpassword
     namespace: openstack
   data:
     NodeRootPassword: "cEBzc3cwcmQh"

   Set the NodeRootPassword parameter to your base64 encoded password.

3. Create the userpassword Secret:

   $ oc create -f openstack-userpassword.yaml -n openstack

Procedure

1. Create a file named osnetconfig.yaml on your workstation. Include the resource specification for the control plane network, which is named ctlplane. For example, the specification for a control plane that uses a Linux bridge connected to the enp6s0 Ethernet device on each worker node is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     # optional: configure static mapping for the networks per nodes. If there is none, a random gets created
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140

   Set the following values in the networks specification:

   name

   Set to the name of the control plane network, which is Control.

   nameLower

   Set to the lower name of the control plane network, which is ctlplane.

   subnets

   Set the subnet specifications.

   subnets.name

   Set the name of the control plane subnet, which is ctlplane.

   subnets.attachConfiguration

   Set the reference to which of the attach configuration should be used.

   subnets.ipv4

   Details of the ipv4 subnet with allocationStart, allocationEnd, cidr, gateway and optional list of routes (with destination and nexthop)

   For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstacknetconfig CRD:

   $ oc describe crd openstacknetconfig

   Save the file when you have finished configuring the network specification.

2. Create the control plane network:

   $ oc create -f osnetconfig.yaml -n openstack

Verification

1. View the resource for the control plane network:

   $ oc get openstacknetconfig/openstacknetconfig

Procedure

1. Create a file for your network configuration. Include the resource specification for the VLAN network. For example, the specification for internal API, storage, storage mgmt, tenant, and external network that manages VLAN-tagged traffic over Linux bridges br-ex and br-osp connected to the enp6s0 and enp7s0 Ethernet device on each worker node is as follows:

   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 172.22.0.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.10
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1500
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
         vlan: 30
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1500
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
         vlan: 40
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1500
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
         vlan: 50
         attachConfiguration: br-osp

   When you use VLAN for network isolation with linux-bridge the following happens:

   • The director Operator creates a Node Network Configuration Policy for the bridge interface specified in the resource, which uses nmstate to configure the bridge on worker nodes.
   • The director Operator creates a Network Attach Definition for each network, which defines the Multus CNI plugin configuration. When you specify the VLAN ID on the Network Attach Definition, the Multus CNI plugin enables vlan-filtering on the bridge.
   • The director Operator attaches a dedicated interface for each network on a virtual machine. This means that the network template for the OpenStackVMSet is a multi-NIC network template.

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the OpenStackNetConfig.

   spec

   Set the network configuration for attaching the networks and the network specifics. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstacknetconfig CRD:

   $ oc describe crd openstacknetconfig

   Save the file when you have finished configuring the network specification.

2. Create the network configuration:

   $ oc apply -f openstacknetconfig.yaml -n openstack

Verification

1. View the OpenStackNetConfig API and created child resources:

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

   If you see errors, check the underlying network-attach-definition and node network configuration policies:

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

Procedure

1. Navigate to the location of your custom templates:

   $ cd ~/custom_templates

2. Archive the templates into a tarball:

   $ tar -cvzf custom-config.tar.gz *.yaml

3. Create the tripleo-tarball-config ConfigMap and use the tarball as data:

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

Verification

1. View the ConfigMap:

   $ oc get configmap/tripleo-tarball-config -n openstack

Procedure

1. Create the heat-env-config ConfigMap and use the directory that contains the environment files as data:

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

Verification

1. View the ConfigMap:

   $ oc get configmap/heat-env-config -n openstack

Procedure

1. Create a file named openstack-controller.yaml on your workstation. Include the resource specification for the Controller nodes. For example, the specification for a control plane that consists of 3 Controller nodes is as follows:

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 500
           baseImageVolumeName: openstack-base-img
           # storageClass must support RWX to be able to live migrate VMs
           storageClass: host-nfs-storageclass
           storageAccessMode:  ReadWriteMany
           # When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
           # specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks.
           # With virtual machine disks, RBD block mode volumes are more efficient and provide better
           # performance than Ceph FS or RBD filesystem-mode PVCs.
           # To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
           # VolumeMode: Block.
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "16.2"

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the overcloud control plane, which is overcloud.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   Set the configuration for the control plane. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstackcontrolplane CRD:

   $ oc describe crd openstackcontrolplane

   Save the file when you have finished configuring the control plane specification.

2. Create the control plane:

   $ oc create -f openstack-controller.yaml -n openstack

   Wait until OCP creates the resources related to OpenStackControlPlane resource.

   As a part of the OpenStackControlPlane resource, the director Operator also creates an OpenStackClient pod that you can access through a remote shell and run RHOSP commands.

Verification

1. View the resource for the control plane:

   $ oc get openstackcontrolplane/overcloud -n openstack

2. View the OpenStackVMSet resources to verify the creation of the control plane virtual machine set:

   $ oc get openstackvmsets -n openstack

3. View the virtual machine resources to verify the creation of the control plane virtual machines in OpenShift Virtualization:

   $ oc get virtualmachines

4. Test access to the openstackclient remote shell:

   $ oc rsh -n openstack openstackclient

Procedure

1. Create a file named openstack-provision.yaml on your workstation. Include the resource specification for the Provisioning server. For example, the specification for a Provisioning server using a specific RHEL 8.4 QCOW2 images:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackProvisionServer
   metadata:
     name: openstack-provision-server
     namespace: openstack
   spec:
     baseImageUrl: http://<source_host>/rhel-guest-image-8.4-992.x86_64.qcow2
     port: 8080

   Set the following values in the resource specification:

   metadata.name

   Set a name to identify the OpenStackProvisionServer.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   baseImageURL

   Set the initial source of the RHEL QCOW2 image for the Provisioing server. The image is download from this remote source when the server is created.

   port

   By default, set to 8080. You can change it for a specific port configuration.

   For further descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the OpenStackProvisionServer CRD:

   $ oc describe crd openstackprovisionserver

   Save the file when you have finished configuring the Provisioning server specification.

2. Create the Provisioning Server:

   $ oc create -f openstack-provision-server.yaml -n openstack

Verification

1. View the resource for the Provisioning server:

   $ oc get openstackprovisionserver/openstack-provision-server -n openstack

Procedure

1. Create a file named openstack-compute.yaml on your workstation. Include the resource specification for the Compute nodes. For example, the specification for 1 Compute node is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: compute
     namespace: openstack
   spec:
     count: 1
     baseImageUrl: http://host/images/rhel-image-8.4.x86_64.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     # If you manually created an OpenStackProvisionServer, you can use it here,
     # otherwise the director Operator will create one for you (with `baseImageUrl` as the image that it server)
     # to use with this OpenStackBaremetalSet
     # provisionServerName: openstack-provision-server
     ctlplaneInterface: enp2s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
     roleName: Compute
     passwordSecret: userpassword

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the Compute node bare metal set, which is overcloud.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   Set the configuration for the Compute nodes. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstackbaremetalset CRD:

   $ oc describe crd openstackbaremetalset

   Save the file when you have finished configuring the Compute node specification.

2. Create the Compute nodes:

   $ oc create -f openstack-compute.yaml -n openstack

Verification

1. View the resource for the Compute nodes:

   $ oc get openstackbaremetalset/compute -n openstack

2. View the bare metal machines that OpenShift manages to verify the creation of the Compute nodes:

   $ oc get baremetalhosts -n openshift-machine-api

Procedure

1. Create a file named openstack-config-generator.yaml on your workstation. Include the resource specification to generate the Ansible playbooks. For example, the specification to generate the playbooks is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     enableFencing: true
     gitSecret: git-secret
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
     heatEnvConfigMap: heat-env-config
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs:
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the Compute node bare metal set, by default default.

   metadata.namespace

   Set to the director Operator namespace, by default openstack.

   spec.enableFencing

   Enable the automatic creation of required heat environment files to enable fencing.

   Note

   Production OSP environments must have fencing enabled. Virtual machines running pacemaker require the fence-agents-kubevirt package.

   spec.gitSecret

   Set to the ConfigMap that contains the Git authentication credentials, by default git-secret.

   spec.heatEnvs

   A list of default tripleo environment files used to generate the playbooks.

   spec.heatEnvConfigMap

   Set to the ConfigMap that contains your custom environment files, by default heat-env-config.

   spec.tarballConfigMap

   Set to the ConfigMap that contains the tarball with your custom heat templates, by default tripleo-tarball-config.

   For more descriptions of the values you can use in the spec section, view the specification schema in the custom resource definition for the openstackconfiggenerator CRD:

   $ oc describe crd openstackconfiggenerator

   Save the file when you have finished configuring the Ansible config generator specification.

2. Create the Ansible config generator:

   $ oc create -f openstack-config-generator.yaml -n openstack

Verification

1. View the resource for the config generator:

   $ oc get openstackconfiggenerator/default -n openstack

Procedure

1. Access the remote shell for openstackclient:

   $ 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-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         - ansible-2.9-for-rhel-8-x86_64-rpms
         - openstack-16.2-for-rhel-8-x86_64-rpms
         - fast-datapath-for-rhel-8-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 8.4
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   This play contains the following three tasks:

   • Register the node.
   • Disable any auto-enabled repositories.
   • Enable only the repositories relevant to the Controller node. The repositories are listed with the repos variable.

4. Register the overcloud nodes to required repositories:

   ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

Procedure

1. Select the hash/digest of the latest OpenStackConfigVersion:

   $ oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o json

Procedure

1. Create a file named openstack-deployment.yaml on your workstation. Include the resource specification to the Ansible playbooks. For example:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h…
     configGenerator: default

   Set the following values in the resource specification:

   metadata.name

   Set the name of the Compute node baremetal set, by default default.

   metadata.namespace

   Set to the diretor Operator namespace, by default openstack.

   spec.configVersion

   The config version/git hash of the playbooks to deploy.

   spec.configGenerator

   The name of the configGenerator.

   For more descriptions of the values you can use inthe spec section, view the specification schema in the custom resource definition of the openstackdeploy CRD:

   $ oc describe crd openstackdeploy

   Save the file when you have finished configuring the OpenStackDeploy specification.

2. 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 tail the logs of the job to watch the Ansible playbooks running:

   $ oc logs -f jobs/deploy-openstack-default

   Additionally, you can manually access the executed Ansible playbooks by logging into the openstackclient pod. In the /home/cloud-admin/work/directory you can find the ansible playbooks and the ansible.log file for the current deployment.

Procedure

1. The default QCOW2 image that you have downloaded from access.redhat.com does not use biosdev predictable network interface names. Modify the image with virt-customize to use biosdev predictable network interface names:

   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(kernelopts=.*\)net.ifnames=0 \(.*\)/\1\2/" /boot/grub2/grubenv'
   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net.ifnames=0 \(.*\)/\1\2/" /etc/default/grub' --truncate /etc/machine-id

2. Upload the image to OpenShift Virtualization with virtctl:

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • Replace <datavolume_name> with the name of the data volume, for example, openstack-base-img.
   • Replace <size> with the size of the data volume required for your environment, for example, 500Gi. The minimum size is 500GB.

   • Replace <storage_class> with the required storage class from your cluster. Use the following command to retrieve the available storage classes:

     $ oc get storageclass

   • Replace <access_mode> with the access mode for the PVC. The default value is ReadWriteOnce.

3. When you create the OpenStackControlPlane resource and individual OpenStackVmSet resources, set the baseImageVolumeName parameter to the data volume name:

   ...
   spec:
     ...
     baseImageVolumeName: openstack-base-img
   ...

Procedure

1. Create the Secret resource:

   $ oc create secret generic git-secret -n openstack --from-file=git_ssh_identity=<path_to_private_SSH_key> --from-literal=git_url=<git_server_URL>

   The git-secret Secret resource contains two key-value pairs:

   git_ssh_identity

   The private key to access the Git repository. The --from-file option stores the content of the private SSH key file.

   git_url

   The SSH URL of the git repository to store the configuration. The --from-literal option stores the URL that you enter for this key.

Verification

1. View the Secret resource:

   $ oc get secret/git-secret -n openstack

Procedure

1. Convert your chosen password to a base64 value:

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   Note

   The -n option removes the trailing newline from the echo output.

2. Create a file named openstack-userpassword.yaml on your workstation. Include the following resource specification for the Secret in the file:

   apiVersion: v1
   kind: Secret
   metadata:
     name: userpassword
     namespace: openstack
   data:
     NodeRootPassword: "cEBzc3cwcmQh"

   Set the NodeRootPassword parameter to your base64 encoded password.

3. Create the userpassword Secret:

   $ oc create -f openstack-userpassword.yaml -n openstack

Procedure

1. Create a file named osnetconfig.yaml on your workstation. Include the resource specification for the control plane network, which is named ctlplane. For example, the specification for a control plane that uses a Linux bridge connected to the enp6s0 Ethernet device on each worker node is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     # optional: configure static mapping for the networks per nodes. If there is none, a random gets created
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140

   Set the following values in the networks specification:

   name

   Set to the name of the control plane network, which is Control.

   nameLower

   Set to the lower name of the control plane network, which is ctlplane.

   subnets

   Set the subnet specifications.

   subnets.name

   Set the name of the control plane subnet, which is ctlplane.

   subnets.attachConfiguration

   Set the reference to which of the attach configuration should be used.

   subnets.ipv4

   Details of the ipv4 subnet with allocationStart, allocationEnd, cidr, gateway and optional list of routes (with destination and nexthop)

   For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstacknetconfig CRD:

   $ oc describe crd openstacknetconfig

   Save the file when you have finished configuring the network specification.

2. Create the control plane network:

   $ oc create -f osnetconfig.yaml -n openstack

Verification

1. View the resource for the control plane network:

   $ oc get openstacknetconfig/openstacknetconfig

Procedure

1. Create a file for your network configuration. Include the resource specification for the VLAN network. For example, the specification for internal API, storage, storage mgmt, tenant, and external network that manages VLAN-tagged traffic over Linux bridges br-ex and br-osp connected to the enp6s0 and enp7s0 Ethernet device on each worker node is as follows:

   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 172.22.0.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.10
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1500
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
         vlan: 30
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1500
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
         vlan: 40
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1500
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
         vlan: 50
         attachConfiguration: br-osp

   When you use VLAN for network isolation with linux-bridge the following happens:

   • The director Operator creates a Node Network Configuration Policy for the bridge interface specified in the resource, which uses nmstate to configure the bridge on worker nodes.
   • The director Operator creates a Network Attach Definition for each network, which defines the Multus CNI plugin configuration. When you specify the VLAN ID on the Network Attach Definition, the Multus CNI plugin enables vlan-filtering on the bridge.
   • The director Operator attaches a dedicated interface for each network on a virtual machine. This means that the network template for the OpenStackVMSet is a multi-NIC network template.

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the OpenStackNetConfig.

   spec

   Set the network configuration for attaching the networks and the network specifics. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstacknetconfig CRD:

   $ oc describe crd openstacknetconfig

   Save the file when you have finished configuring the network specification.

2. Create the network configuration:

   $ oc apply -f openstacknetconfig.yaml -n openstack

Verification

1. View the OpenStackNetConfig API and created child resources:

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

   If you see errors, check the underlying network-attach-definition and node network configuration policies:

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

Procedure

1. Create a file named openstack-controller.yaml on your workstation. Include the resource specification for the Controller nodes. For example, the specification for a control plane that consists of 3 Controller nodes is as follows:

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 500
           baseImageVolumeName: openstack-base-img
           # storageClass must support RWX to be able to live migrate VMs
           storageClass: host-nfs-storageclass
           storageAccessMode:  ReadWriteMany
           # When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
           # specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks.
           # With virtual machine disks, RBD block mode volumes are more efficient and provide better
           # performance than Ceph FS or RBD filesystem-mode PVCs.
           # To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
           # VolumeMode: Block.
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "16.2"

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the overcloud control plane, which is overcloud.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   Set the configuration for the control plane. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstackcontrolplane CRD:

   $ oc describe crd openstackcontrolplane

   Save the file when you have finished configuring the control plane specification.

2. Create the control plane:

   $ oc create -f openstack-controller.yaml -n openstack

   Wait until OCP creates the resources related to OpenStackControlPlane resource.

   As a part of the OpenStackControlPlane resource, the director Operator also creates an OpenStackClient pod that you can access through a remote shell and run RHOSP commands.

Verification

1. View the resource for the control plane:

   $ oc get openstackcontrolplane/overcloud -n openstack

2. View the OpenStackVMSet resources to verify the creation of the control plane virtual machine set:

   $ oc get openstackvmsets -n openstack

3. View the virtual machine resources to verify the creation of the control plane virtual machines in OpenShift Virtualization:

   $ oc get virtualmachines

4. Test access to the openstackclient remote shell:

   $ oc rsh -n openstack openstackclient

Procedure

1. Create a directory for your custom templates:

   $ mkdir custom_templates

2. Create a directory for your custom environment files:

   $ mkdir custom_environment_files

Procedure

1. Access the remote shell for openstackclient:

   $ oc rsh -n openstack openstackclient

2. Unset the OS_CLOUD environment variable:

   $ unset OS_CLOUD

3. Change to the cloud-admin directory:

   $ cd /home/cloud-admin/

4. Generate a new roles_data.yaml file with the Controller and ComputeHCI roles:

   $ openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml

5. Exit the openstackclient pod:

   $ exit

6. Copy the custom roles_data.yaml file from the openstackclient pod to your custom templates directory:

   $ oc cp openstackclient:/home/cloud-admin/roles_data.yaml custom_templates/roles_data.yaml -n openstack

Procedure

1. Navigate to the location of your custom templates:

   $ cd ~/custom_templates

2. Archive the templates into a tarball:

   $ tar -cvzf custom-config.tar.gz *.yaml

3. Create the tripleo-tarball-config ConfigMap and use the tarball as data:

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

Verification

1. View the ConfigMap:

   $ oc get configmap/tripleo-tarball-config -n openstack

Procedure

1. Create the heat-env-config ConfigMap and use the directory that contains the environment files as data:

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

Verification

1. View the ConfigMap:

   $ oc get configmap/heat-env-config -n openstack

Procedure

1. Create a file named openstack-hcicompute.yaml on your workstation. Include the resource specification for the Compute nodes. For example, the specification for 1 Compute node is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: computehci
     namespace: openstack
   spec:
     count: 3
     baseImageUrl: http://host/images/rhel-image-8.4.x86_64.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     ctlplaneInterface: enp8s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
       - storage_mgmt
     roleName: ComputeHCI
     passwordSecret: userpassword

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the Compute node bare metal set, which is overcloud.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   Set the configuration for the Compute nodes. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstackbaremetalset CRD:

   $ oc describe crd openstackbaremetalset

   Save the file when you have finished configuring the Compute node specification.

2. Create the Compute nodes:

   $ oc create -f openstack-hcicompute.yaml -n openstack

Verification

1. View the resource for the Compute HCI nodes:

   $ oc get openstackbaremetalset/computehci -n openstack

2. View the bare metal machines that OpenShift manages to verify the creation of the Compute HCI nodes:

   $ oc get baremetalhosts -n openshift-machine-api

Procedure

1. Create a file named openstack-config-generator.yaml on your workstation. Include the resource specification to generate the Ansible playbooks. For example, the specification to generate the playbooks is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     enableFencing: true
     gitSecret: git-secret
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
     heatEnvConfigMap: heat-env-config
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs:
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the Compute node bare metal set, by default default.

   metadata.namespace

   Set to the director Operator namespace, by default openstack.

   spec.enableFencing

   Enable the automatic creation of required heat environment files to enable fencing.

   Note

   Production OSP environments must have fencing enabled. Virtual machines running pacemaker require the fence-agents-kubevirt package.

   spec.gitSecret

   Set to the ConfigMap that contains the Git authentication credentials, by default git-secret.

   spec.heatEnvs

   A list of default tripleo environment files used to generate the playbooks.

   spec.heatEnvConfigMap

   Set to the ConfigMap that contains your custom environment files, by default heat-env-config.

   spec.tarballConfigMap

   Set to the ConfigMap that contains the tarball with your custom heat templates, by default tripleo-tarball-config.

   For more descriptions of the values you can use in the spec section, view the specification schema in the custom resource definition for the openstackconfiggenerator CRD:

   $ oc describe crd openstackconfiggenerator

   Save the file when you have finished configuring the Ansible config generator specification.

2. Create the Ansible config generator:

   $ oc create -f openstack-config-generator.yaml -n openstack

Verification

1. View the resource for the config generator:

   $ oc get openstackconfiggenerator/default -n openstack

Procedure

1. Access the remote shell for openstackclient:

   $ 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-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         - ansible-2.9-for-rhel-8-x86_64-rpms
         - openstack-16.2-for-rhel-8-x86_64-rpms
         - fast-datapath-for-rhel-8-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 8.4
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   This play contains the following three tasks:

   • Register the node.
   • Disable any auto-enabled repositories.
   • Enable only the repositories relevant to the Controller node. The repositories are listed with the repos variable.

4. Register the overcloud nodes to required repositories:

   ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

Procedure

1. Create a file named openstack-deployment.yaml on your workstation. Include the resource specification to the Ansible playbooks. For example:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h…
     configGenerator: default

   Set the following values in the resource specification:

   metadata.name

   Set the name of the Compute node baremetal set, by default default.

   metadata.namespace

   Set to the diretor Operator namespace, by default openstack.

   spec.configVersion

   The config version/git hash of the playbooks to deploy.

   spec.configGenerator

   The name of the configGenerator.

   For more descriptions of the values you can use inthe spec section, view the specification schema in the custom resource definition of the openstackdeploy CRD:

   $ oc describe crd openstackdeploy

   Save the file when you have finished configuring the OpenStackDeploy specification.

2. 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 tail the logs of the job to watch the Ansible playbooks running:

   $ oc logs -f jobs/deploy-openstack-default

   Additionally, you can manually access the executed Ansible playbooks by logging into the openstackclient pod. In the /home/cloud-admin/work/directory you can find the ansible playbooks and the ansible.log file for the current deployment.

Procedure

1. The default QCOW2 image that you have downloaded from access.redhat.com does not use biosdev predictable network interface names. Modify the image with virt-customize to use biosdev predictable network interface names:

   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(kernelopts=.*\)net.ifnames=0 \(.*\)/\1\2/" /boot/grub2/grubenv'
   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net.ifnames=0 \(.*\)/\1\2/" /etc/default/grub' --truncate /etc/machine-id

2. Upload the image to OpenShift Virtualization with virtctl:

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • Replace <datavolume_name> with the name of the data volume, for example, openstack-base-img.
   • Replace <size> with the size of the data volume required for your environment, for example, 500Gi. The minimum size is 500GB.

   • Replace <storage_class> with the required storage class from your cluster. Use the following command to retrieve the available storage classes:

     $ oc get storageclass

   • Replace <access_mode> with the access mode for the PVC. The default value is ReadWriteOnce.

3. When you create the OpenStackControlPlane resource and individual OpenStackVmSet resources, set the baseImageVolumeName parameter to the data volume name:

   ...
   spec:
     ...
     baseImageVolumeName: openstack-base-img
   ...

Procedure

1. Create the Secret resource:

   $ oc create secret generic git-secret -n openstack --from-file=git_ssh_identity=<path_to_private_SSH_key> --from-literal=git_url=<git_server_URL>

   The git-secret Secret resource contains two key-value pairs:

   git_ssh_identity

   The private key to access the Git repository. The --from-file option stores the content of the private SSH key file.

   git_url

   The SSH URL of the git repository to store the configuration. The --from-literal option stores the URL that you enter for this key.

Verification

1. View the Secret resource:

   $ oc get secret/git-secret -n openstack

Procedure

1. Convert your chosen password to a base64 value:

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   Note

   The -n option removes the trailing newline from the echo output.

2. Create a file named openstack-userpassword.yaml on your workstation. Include the following resource specification for the Secret in the file:

   apiVersion: v1
   kind: Secret
   metadata:
     name: userpassword
     namespace: openstack
   data:
     NodeRootPassword: "cEBzc3cwcmQh"

   Set the NodeRootPassword parameter to your base64 encoded password.

3. Create the userpassword Secret:

   $ oc create -f openstack-userpassword.yaml -n openstack

Procedure

1. Create a file named osnetconfig.yaml on your workstation. Include the resource specification for the control plane network, which is named ctlplane. For example, the specification for a control plane that uses a Linux bridge connected to the enp6s0 Ethernet device on each worker node is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     # optional: configure static mapping for the networks per nodes. If there is none, a random gets created
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140

   Set the following values in the networks specification:

   name

   Set to the name of the control plane network, which is Control.

   nameLower

   Set to the lower name of the control plane network, which is ctlplane.

   subnets

   Set the subnet specifications.

   subnets.name

   Set the name of the control plane subnet, which is ctlplane.

   subnets.attachConfiguration

   Set the reference to which of the attach configuration should be used.

   subnets.ipv4

   Details of the ipv4 subnet with allocationStart, allocationEnd, cidr, gateway and optional list of routes (with destination and nexthop)

   For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstacknetconfig CRD:

   $ oc describe crd openstacknetconfig

   Save the file when you have finished configuring the network specification.

2. Create the control plane network:

   $ oc create -f osnetconfig.yaml -n openstack

Verification

1. View the resource for the control plane network:

   $ oc get openstacknetconfig/openstacknetconfig

Procedure

1. Create a file for your network configuration. Include the resource specification for the VLAN network. For example, the specification for internal API, storage, storage mgmt, tenant, and external network that manages VLAN-tagged traffic over Linux bridges br-ex and br-osp connected to the enp6s0 and enp7s0 Ethernet device on each worker node is as follows:

   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 172.22.0.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.10
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1500
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
         vlan: 30
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1500
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
         vlan: 40
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1500
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
         vlan: 50
         attachConfiguration: br-osp

   When you use VLAN for network isolation with linux-bridge the following happens:

   • The director Operator creates a Node Network Configuration Policy for the bridge interface specified in the resource, which uses nmstate to configure the bridge on worker nodes.
   • The director Operator creates a Network Attach Definition for each network, which defines the Multus CNI plugin configuration. When you specify the VLAN ID on the Network Attach Definition, the Multus CNI plugin enables vlan-filtering on the bridge.
   • The director Operator attaches a dedicated interface for each network on a virtual machine. This means that the network template for the OpenStackVMSet is a multi-NIC network template.

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the OpenStackNetConfig.

   spec

   Set the network configuration for attaching the networks and the network specifics. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstacknetconfig CRD:

   $ oc describe crd openstacknetconfig

   Save the file when you have finished configuring the network specification.

2. Create the network configuration:

   $ oc apply -f openstacknetconfig.yaml -n openstack

Verification

1. View the OpenStackNetConfig API and created child resources:

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

   If you see errors, check the underlying network-attach-definition and node network configuration policies:

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

Procedure

1. Create a file named openstack-controller.yaml on your workstation. Include the resource specification for the Controller nodes. For example, the specification for a control plane that consists of 3 Controller nodes is as follows:

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 500
           baseImageVolumeName: openstack-base-img
           # storageClass must support RWX to be able to live migrate VMs
           storageClass: host-nfs-storageclass
           storageAccessMode:  ReadWriteMany
           # When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
           # specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks.
           # With virtual machine disks, RBD block mode volumes are more efficient and provide better
           # performance than Ceph FS or RBD filesystem-mode PVCs.
           # To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
           # VolumeMode: Block.
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "16.2"

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the overcloud control plane, which is overcloud.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   Set the configuration for the control plane. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstackcontrolplane CRD:

   $ oc describe crd openstackcontrolplane

   Save the file when you have finished configuring the control plane specification.

2. Create the control plane:

   $ oc create -f openstack-controller.yaml -n openstack

   Wait until OCP creates the resources related to OpenStackControlPlane resource.

   As a part of the OpenStackControlPlane resource, the director Operator also creates an OpenStackClient pod that you can access through a remote shell and run RHOSP commands.

Verification

1. View the resource for the control plane:

   $ oc get openstackcontrolplane/overcloud -n openstack

2. View the OpenStackVMSet resources to verify the creation of the control plane virtual machine set:

   $ oc get openstackvmsets -n openstack

3. View the virtual machine resources to verify the creation of the control plane virtual machines in OpenShift Virtualization:

   $ oc get virtualmachines

4. Test access to the openstackclient remote shell:

   $ oc rsh -n openstack openstackclient

Procedure

1. Create a directory for your custom templates:

   $ mkdir custom_templates

2. Create a directory for your custom environment files:

   $ mkdir custom_environment_files

Procedure

1. Navigate to the location of your custom templates:

   $ cd ~/custom_templates

2. Archive the templates into a tarball:

   $ tar -cvzf custom-config.tar.gz *.yaml

3. Create the tripleo-tarball-config ConfigMap and use the tarball as data:

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

Verification

1. View the ConfigMap:

   $ oc get configmap/tripleo-tarball-config -n openstack

Procedure

1. Create the heat-env-config ConfigMap and use the directory that contains the environment files as data:

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

Verification

1. View the ConfigMap:

   $ oc get configmap/heat-env-config -n openstack

Procedure

1. Create a file named openstack-compute.yaml on your workstation. Include the resource specification for the Compute nodes. For example, the specification for 1 Compute node is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: compute
     namespace: openstack
   spec:
     count: 1
     baseImageUrl: http://host/images/rhel-image-8.4.x86_64.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     # If you manually created an OpenStackProvisionServer, you can use it here,
     # otherwise the director Operator will create one for you (with `baseImageUrl` as the image that it server)
     # to use with this OpenStackBaremetalSet
     # provisionServerName: openstack-provision-server
     ctlplaneInterface: enp2s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
     roleName: Compute
     passwordSecret: userpassword

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the Compute node bare metal set, which is overcloud.

   metadata.namespace

   Set to the director Operator namespace, which is openstack.

   spec

   Set the configuration for the Compute nodes. For descriptions of the values you can use in this section, view the specification schema in the custom resource definition for the openstackbaremetalset CRD:

   $ oc describe crd openstackbaremetalset

   Save the file when you have finished configuring the Compute node specification.

2. Create the Compute nodes:

   $ oc create -f openstack-compute.yaml -n openstack

Verification

1. View the resource for the Compute nodes:

   $ oc get openstackbaremetalset/compute -n openstack

2. View the bare metal machines that OpenShift manages to verify the creation of the Compute nodes:

   $ oc get baremetalhosts -n openshift-machine-api

Procedure

1. Create a file named openstack-config-generator.yaml on your workstation. Include the resource specification to generate the Ansible playbooks. For example, the specification to generate the playbooks is as follows:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     enableFencing: true
     gitSecret: git-secret
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
     heatEnvConfigMap: heat-env-config
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs:
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config

   Set the following values in the resource specification:

   metadata.name

   Set to the name of the Compute node bare metal set, by default default.

   metadata.namespace

   Set to the director Operator namespace, by default openstack.

   spec.enableFencing

   Enable the automatic creation of required heat environment files to enable fencing.

   Note

   Production OSP environments must have fencing enabled. Virtual machines running pacemaker require the fence-agents-kubevirt package.

   spec.gitSecret

   Set to the ConfigMap that contains the Git authentication credentials, by default git-secret.

   spec.heatEnvs

   A list of default tripleo environment files used to generate the playbooks.

   spec.heatEnvConfigMap

   Set to the ConfigMap that contains your custom environment files, by default heat-env-config.

   spec.tarballConfigMap

   Set to the ConfigMap that contains the tarball with your custom heat templates, by default tripleo-tarball-config.

   For more descriptions of the values you can use in the spec section, view the specification schema in the custom resource definition for the openstackconfiggenerator CRD:

   $ oc describe crd openstackconfiggenerator

   Save the file when you have finished configuring the Ansible config generator specification.

2. Create the Ansible config generator:

   $ oc create -f openstack-config-generator.yaml -n openstack

Verification

1. View the resource for the config generator:

   $ oc get openstackconfiggenerator/default -n openstack

Procedure

1. Access the remote shell for openstackclient:

   $ 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-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         - ansible-2.9-for-rhel-8-x86_64-rpms
         - openstack-16.2-for-rhel-8-x86_64-rpms
         - fast-datapath-for-rhel-8-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 8.4
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   This play contains the following three tasks:

   • Register the node.
   • Disable any auto-enabled repositories.
   • Enable only the repositories relevant to the Controller node. The repositories are listed with the repos variable.

4. Register the overcloud nodes to required repositories:

   ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

Procedure

1. Create a file named openstack-deployment.yaml on your workstation. Include the resource specification to the Ansible playbooks. For example:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h…
     configGenerator: default

   Set the following values in the resource specification:

   metadata.name

   Set the name of the Compute node baremetal set, by default default.

   metadata.namespace

   Set to the diretor Operator namespace, by default openstack.

   spec.configVersion

   The config version/git hash of the playbooks to deploy.

   spec.configGenerator

   The name of the configGenerator.

   For more descriptions of the values you can use inthe spec section, view the specification schema in the custom resource definition of the openstackdeploy CRD:

   $ oc describe crd openstackdeploy

   Save the file when you have finished configuring the OpenStackDeploy specification.

2. 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 tail the logs of the job to watch the Ansible playbooks running:

   $ oc logs -f jobs/deploy-openstack-default

   Additionally, you can manually access the executed Ansible playbooks by logging into the openstackclient pod. In the /home/cloud-admin/work/directory you can find the ansible playbooks and the ansible.log file for the current deployment.

Procedure

1. Access the remote shell for openstackclient:

   $ oc rsh -n openstack openstackclient

2. Change to the cloud-admin home directory:

   $ cd /home/cloud-admin

3. Run your openstack commands. For example, you can create a default network with the following command:

   $ openstack network create default

Procedure

1. Optional: To login as the admin user, obtain the admin password from the AdminPassword parameter in the tripleo-passwords secret:

   $ oc get secret tripleo-passwords -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d

2. Open your web browser.
3. Enter the host name or public VIP of the overcloud dashboard in the URL field.
4. Log in to the dashboard with your chosen username and password.

Procedure

1. Modify the YAML configuration for the compute OpenStackBaremetalSet and increase count parameter for the resource:

   $ oc patch osbms compute --type=merge --patch '{"spec":{"count":3}}' -n openstack

2. The OpenStackBaremetalSet resource automatically provisions new nodes with the Red Hat Enterprise Linux base operating system. Wait until the provisioning process completes. Check the nodes periodically to determine the readiness of the nodes:

   $ oc get baremetalhosts -n openshift-machine-api
   $ oc get openstackbaremetalset

3. Generate the Ansible Playbooks using OpenStackConfigGenerator, see Configuring overcloud software with the director Operator.

Procedure

1. Access the remote shell for openstackclient:

   $ oc rsh -n openstack openstackclient

2. Identify the Compute node that you want to remove:

   $ openstack compute service list

3. Disable the Compute service on the node to prevent the node from scheduling new instances:

   $ openstack compute service set <hostname> nova-compute --disable

4. Annotate the bare-metal node to prevent Metal³ from starting the node:

   $ oc annotate baremetalhost <node> baremetalhost.metal3.io/detached=true
   $ oc logs --since=1h <metal3-pod> metal3-baremetal-operator | grep -i detach
   $ oc get baremetalhost <node> -o json | jq .status.operationalStatus
   "detached"

   • Replace <node> with the name of the BareMetalHost resource.
   • Replace <metal3-pod> with the name of your metal3 pod.

5. Log in to the Compute node as the root user and shut down the bare-metal node:

   [root@compute-0 ~]# shutdown -h now

   If the Compute node is not accessible, complete the following steps:

   1. Log in to a Controller node as the root user.

   2. If Instance HA is enabled, disable the STONITH device for the Compute node:

      [root@controller-0 ~]# pcs stonith disable <stonith_resource_name>

      • Replace <stonith_resource_name> with the name of the STONITH resource that corresponds to the node. The resource name uses the the format <resource_agent>-<host_mac>. You can find the resource agent and the host MAC address in the FencingConfig section of the fencing.yaml file.
   3. Use IPMI to power off the bare-metal node. For more information, see your hardware vendor documentation.

6. Retrieve the BareMetalHost resource that corresponds to the node that you want to remove:

   $ oc get openstackbaremetalset compute -o json | jq '.status.baremetalHosts | to_entries[] | "\(.key) => \(.value | .hostRef)"'
   "compute-0, openshift-worker-3"
   "compute-1, openshift-worker-4"

7. To change the status of the annotatedForDeletion parameter to true in the OpenStackBaremetalSet resource, annotate the BareMetalHost resource with osp-director.openstack.org/delete-host=true:

   $ oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite

8. Optional: Confirm that the annotatedForDeletion status has changed to true in the OpenStackBaremetalSet resource:

   $ oc get openstackbaremetalset compute -o json -n openstack | jq .status
   {
     "baremetalHosts": {
       "compute-0": {
         "annotatedForDeletion": true,
         "ctlplaneIP": "192.168.25.105/24",
         "hostRef": "openshift-worker-3",
         "hostname": "compute-0",
         "networkDataSecretName": "compute-cloudinit-networkdata-openshift-worker-3",
         "provisioningState": "provisioned",
         "userDataSecretName": "compute-cloudinit-userdata-openshift-worker-3"
       },
       "compute-1": {
         "annotatedForDeletion": false,
         "ctlplaneIP": "192.168.25.106/24",
         "hostRef": "openshift-worker-4",
         "hostname": "compute-1",
         "networkDataSecretName": "compute-cloudinit-networkdata-openshift-worker-4",
         "provisioningState": "provisioned",
         "userDataSecretName": "compute-cloudinit-userdata-openshift-worker-4"
       }
     },
     "provisioningStatus": {
       "readyCount": 2,
       "reason": "All requested BaremetalHosts have been provisioned",
       "state": "provisioned"
     }
   }

9. Decrease the count parameter for the compute OpenStackBaremetalSet resource:

   $ oc patch openstackbaremetalset compute --type=merge --patch '{"spec":{"count":1}}' -n openstack

   When you reduce the resource count of the OpenStackBaremetalSet resource, you trigger the corresponding controller to handle the resource deletion, which causes the following actions:

   • Director Operator deletes the corresponding IP reservations from OpenStackIPSet and OpenStackNetConfig for the node.

   • Director Operator flags the IP reservation entry in the OpenStackNet resource as deleted:

     $ oc get osnet ctlplane -o json -n openstack | jq .status.reservations
     {
       "compute-0": {
         "deleted": true,
         "ip": "172.22.0.140"
       },
       "compute-1": {
         "deleted": false,
         "ip": "172.22.0.100"
       },
       "controller-0": {
         "deleted": false,
         "ip": "172.22.0.120"
       },
       "controlplane": {
         "deleted": false,
         "ip": "172.22.0.110"
       },
       "openstackclient-0": {
         "deleted": false,
         "ip": "172.22.0.251"
       }

10. Optional: To make the IP reservations of the deleted OpenStackBaremetalSet resource available for other roles to use, set the value of the spec.preserveReservations parameter to false in the OpenStackNetConfig object.

11. Access the remote shell for openstackclient:

    $ oc rsh openstackclient -n openstack

12. Remove the Compute service entries from the overcloud:

    $ openstack compute service list
    $ openstack compute service delete <service-id>

13. Check the Compute network agents entries in the overcloud and remove them if they exist:

    $ openstack network agent list
    $ for AGENT in $(openstack network agent list --host <scaled-down-node> -c ID -f value) ; do openstack network agent delete $AGENT ; done

14. Exit from openstackclient:

    $ exit

Procedure

1. Modify the heat parameter ConfigMap called fencing.yaml, to disable fencing for the duration of the update:

   parameter_defaults:
     EnableFencing: false

2. Create an OpenStackConfigGenerator resource called osconfiggenerator-update-prepare.yaml:

   $ cat <<EOF > osconfiggenerator-update-prepare.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: "update"
     namespace: openstack
   spec:
     gitSecret: git-secret
     heatEnvs:
       - lifecycle/update-prepare.yaml
     heatEnvConfigMap: heat-env-config-update
     tarballConfigMap: tripleo-tarball-config-update
   EOF

3. Apply the configuration:

   $ oc apply -f osconfiggenerator-update-prepare.yaml

4. Wait until the update preparation process completes.

Procedure

1. Create an osdeploy job called osdeploy-container-image-prepare.yaml:

   $ cat <<EOF > osdeploy-container-image-prepare.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: container_image_prepare
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - container_image_prepare
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-container-image-prepare.yaml

Procedure

1. Create an osdeploy job called osdeploy-ovn-update.yaml:

   $ cat <<EOF > osdeploy-ovn-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ovn-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       tags:
         - ovn
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-ovn-update.yaml

3. Wait until the ovn-controller container update completes.

Procedure

1. Create an osdeploy job called osdeploy-controller-update.yaml:

   $ cat <<EOF > osdeploy-controller-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: controller-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: Controller
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-controller-update.yaml

3. Wait until the Controller node update completes.

Procedure

1. Create an osdeploy job called osdeploy-compute-update.yaml:

   $ cat <<EOF > osdeploy-compute-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: compute-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: Compute
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-compute-update.yaml

3. Wait until the Compute node update completes.

Procedure

1. Create an osdeploy job called osdeploy-computehci-update.yaml:

   $ cat <<EOF > osdeploy-computehci-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: computehci-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: ComputeHCI
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-computehci-update.yaml

3. Wait until the ComputeHCI node update completes.

4. Create an osdeploy job called osdeploy-ceph-update.yaml:

   $ cat <<EOF > osdeploy-ceph-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ceph-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - ceph
   EOF

5. Apply the configuration:

   $ oc apply -f osdeploy-ceph-update.yaml

6. Wait until the Red Hat Ceph Storage node update completes.

Procedure

1. Create an osdeploy job called osdeploy-cephstorage-update.yaml:

   $ cat <<EOF > osdeploy-cephstorage-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: cephstorage-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: CephStorage
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-cephstorage-update.yaml

3. Wait until the Red Hat Ceph Storage node update completes.

4. Create an osdeploy job called osdeploy-ceph-update.yaml:

   $ cat <<EOF > osdeploy-ceph-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ceph-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - ceph
   EOF

5. Apply the configuration:

   $ oc apply -f osdeploy-ceph-update.yaml

6. Wait until the Red Hat Ceph Storage node update completes.

Procedure

1. Create an osdeploy job called osdeploy-online-migration.yaml:

   $ cat <<EOF > osdeploy-online-migration.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: online-migration
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - online_upgrade
   EOF

2. Apply the configuration:

   $ oc apply -f osdeploy-online-migration.yaml

Procedure

1. Re-enable fencing in the fencing.yaml environment file:

   parameter_defaults:
     EnableFencing: true

2. Regenerate the default configuration, ensuring that lifecycle/update-prepare.yaml is not included in the heatEnvs. For more information, see Configuring overcloud software with the director Operator.

3. Delete OpenStackConfigGenerator, ConfigVersion, and configuration deployment resources.

   $ oc delete <type> <name>

   • Replace <type> with the type of resource to delete.
   • Replace <name> with the name of the resource to delete.
4. Wait until the update finalization completes.

Procedure

1. Create a ConfigMap to store the CA certificates. The ConfigMap is the interface used to add CA certificates to the openstackclient pod, using the OpenStackControlPlane object:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cacerts
     namespace: openstack
   data:
    local_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----
     another_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----

2. Create the OpenStackControlPlane and reference the ConfigMap:

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: <overcloud>
     namespace: openstack
   spec:
     caConfigMap: cacerts

   • Replace <overcloud> with the name of your stack.

3. In the ~/custom_environment_files directory create a file called tls-certs.yaml containing the generated certificates for the deployment using SSLCertificate, SSLIntermediateCertificate, SSLKey, and CAMap parameters.

   Note

   For more information on creating a certificate file, see Enabling SSL/TLS.

4. Update the heatEnvConfigMap to add the tls-certs.yaml file:

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

5. Create an OpenStackConfigGenerator and add the required heatEnvs configuration files to configure TLS for public endpoint IPs:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   …
   spec:
     …
     heatEnvs:
       - ssl/tls-endpoints-public-ip.yaml
       - ssl/enable-tls.yaml
     …
     heatEnvConfigMap: heat-env-config
     tarballConfigMap: tripleo-tarball-config

6. The OpenStackConfigGenerator and a new OpenStackConfigVersion are created, run the Ansible playbooks against the overcloud using the OpenStackDeploy resource:

   • Registering the operating system of your overcloud.
   • Obtain the latest OpenStackConfig Version.
   • Applying overcloud configuration with the director Operator.

Procedure

1. Create a ConfigMap to store the CA certificates. The ConfigMap is the interface used to add additional CA certificates to the openstackclient pod, using the OpenStackControlPlane object:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cacerts
     namespace: openstack
   data:
    local_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----
     another_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----

2. Create the OpenStackControlPlane and reference the ConfigMap:

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: <overcloud>
     namespace: openstack
   spec:
     caConfigMap: cacerts

   • Replace <overcloud> with the name of your stack.

3. In the ~/custom_environment_files directory create a file called tls-certs.yaml containing the generated certificates for the deployment using SSLCertificate, SSLIntermediateCertificate, SSLKey, and CAMap parameters.

   Note

   For more information on creating a certificate file, see Enabling SSL/TLS.

4. Update the heatEnvConfigMap to add the tls-certs.yaml file:

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

5. Create an OpenStackConfigGenerator and add the required heatEnvs configuration files to configure TLS for public endpoint DNS names:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   …
   spec:
     …
     heatEnvs:
       - ssl/tls-endpoints-public-dns.yaml
       - ssl/enable-tls.yaml
     …
     heatEnvConfigMap: heat-env-config
     tarballConfigMap: tripleo-tarball-config

6. The OpenStackConfigGenerator and a new OpenStackConfigVersion are created, run the Ansible playbooks against the overcloud using the OpenStackDeploy resource:

   • Registering the operating system of your overcloud.
   • Obtain the latest OpenStackConfig Version.
   • Applying overcloud configuration with the director Operator.

Procedure

1. Create a backup of the current tripleo-passwords secret:

   $ oc get secret tripleo-passwords -n openstack -o yaml > tripleo-passwords_backup.yaml

2. Create a plain text file named tripleo-overcloud-passwords_preserve_list to specify that the passwords for the following services should not be rotated:

   parameter_defaults
   BarbicanSimpleCryptoKek
   KeystoneCredential0
   KeystoneCredential1
   KeystoneFernetKey0
   KeystoneFernetKey1
   KeystoneFernetKeys
   CephClientKey
   CephClusterFSID
   CephManilaClientKey
   CephRgwKey
   HeatAuthEncryptionKey
   MysqlClustercheckPassword
   MysqlMariabackupPassword
   PacemakerRemoteAuthkey
   PcsdPassword

   You can add additional services to this list if there are other services for which you want to preserve the password.

3. Create a password parameter file, tripleo-overcloud-passwords.yaml, that lists the passwords that should not be modified:

   $ oc get secret tripleo-passwords -n openstack \
   -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' \
   | base64 -d | grep -f ./tripleo-overcloud-passwords_preserve_list > tripleo-overcloud-passwords.yaml

4. Validate that the tripleo-overcloud-passwords.yaml file contains the passwords that you do not want to rotate.

5. Update the tripleo-password secret:

   $ oc create secret generic tripleo-passwords -n openstack \
   --from-file=./tripleo-overcloud-passwords.yaml \
   --dry-run=client -o yaml | oc apply -f -

6. Create Ansible playbooks to configure the overcloud with the OpenStackConfigGenerator CRD. For more information, see Creating Ansible playbooks for overcloud configuration with the OpenStackConfigGenerator CRD.
7. Apply the updated configuration. For more information, see Applying overcloud configuration with director Operator.

1. Get the password from the updated secret:

   $ oc get secret tripleo-passwords -n openstack -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d | grep NovaPassword

   Example output:

   NovaPassword: hp4xpt7t2p79ktqjjnxpqwbp6

2. Retrieve the password for the Compute service (nova) running on the Controller nodes:

   1. Access the openstackclient remote shell:

      $ oc rsh openstackclient -n openstack

   2. Ensure that you are in the home directory:

      $ cd

   3. Retrieve the Compute service password:

      $ ansible -i /home/cloud-admin/ctlplane-ansible-inventory Controller -b -a "grep ^connection /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf"

      Example output:

      172.22.0.120 | CHANGED | rc=0 >> connection=mysql+pymysql://nova_api:hp4xpt7t2p79ktqjjnxpqwbp6@172.17.0.10/nova_api?read_default_file=/etc/my.cnf.d/tripleo.cnf&read_default_group=tripleo connection=mysql+pymysql://nova:hp4xpt7t2p79ktqjjnxpqwbp6@172.17.0.10/nova?read_default_file=/etc/my.cnf.d/tripleo.cnf&read_default_group=tripleo

Procedure

1. Create a configuration file called openstacknetconfig.yaml:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 192.168.25.250
           allocationStart: 192.168.25.100
           cidr: 192.168.25.0/24
           gateway: 192.168.25.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
           routes:
           - destination: 172.17.1.0/24
             nexthop: 172.17.0.1
           - destination: 172.17.2.0/24
             nexthop: 172.17.0.1
         vlan: 20
         attachConfiguration: br-osp
       - name: internal_api_leaf1
         ipv4:
           allocationEnd: 172.17.1.250
           allocationStart: 172.17.1.10
           cidr: 172.17.1.0/24
           routes:
           - destination: 172.17.0.0/24
             nexthop: 172.17.1.1
           - destination: 172.17.2.0/24
             nexthop: 172.17.1.1
         vlan: 21
         attachConfiguration: br-osp
       - name: internal_api_leaf2
         ipv4:
           allocationEnd: 172.17.2.250
           allocationStart: 172.17.2.10
           cidr: 172.17.2.0/24
           routes:
           - destination: 172.17.1.0/24
             nexthop: 172.17.2.1
           - destination: 172.17.0.0/24
             nexthop: 172.17.2.1
         vlan: 22
         attachConfiguration: br-osp
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1350
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
           routes:
           - destination: 172.18.1.0/24
             nexthop: 172.18.0.1
           - destination: 172.18.2.0/24
             nexthop: 172.18.0.1
         vlan: 30
         attachConfiguration: br-osp
       - name: storage_leaf1
         ipv4:
           allocationEnd: 172.18.1.250
           allocationStart: 172.18.1.10
           cidr: 172.18.1.0/24
           routes:
           - destination: 172.18.0.0/24
             nexthop: 172.18.1.1
           - destination: 172.18.2.0/24
             nexthop: 172.18.1.1
         vlan: 31
         attachConfiguration: br-osp
       - name: storage_leaf2
         ipv4:
           allocationEnd: 172.18.2.250
           allocationStart: 172.18.2.10
           cidr: 172.18.2.0/24
           routes:
           - destination: 172.18.0.0/24
             nexthop: 172.18.2.1
           - destination: 172.18.1.0/24
             nexthop: 172.18.2.1
         vlan: 32
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1350
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
           routes:
           - destination: 172.19.1.0/24
             nexthop: 172.19.0.1
           - destination: 172.19.2.0/24
             nexthop: 172.19.0.1
         vlan: 40
         attachConfiguration: br-osp
       - name: storage_mgmt_leaf1
         ipv4:
           allocationEnd: 172.19.1.250
           allocationStart: 172.19.1.10
           cidr: 172.19.1.0/24
           routes:
           - destination: 172.19.0.0/24
             nexthop: 172.19.1.1
           - destination: 172.19.2.0/24
             nexthop: 172.19.1.1
         vlan: 41
         attachConfiguration: br-osp
       - name: storage_mgmt_leaf2
         ipv4:
           allocationEnd: 172.19.2.250
           allocationStart: 172.19.2.10
           cidr: 172.19.2.0/24
           routes:
           - destination: 172.19.0.0/24
             nexthop: 172.19.2.1
           - destination: 172.19.1.0/24
             nexthop: 172.19.2.1
         vlan: 42
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1350
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
           routes:
           - destination: 172.20.1.0/24
             nexthop: 172.20.0.1
           - destination: 172.20.2.0/24
             nexthop: 172.20.0.1
         vlan: 50
         attachConfiguration: br-osp
       - name: tenant_leaf1
         ipv4:
           allocationEnd: 172.20.1.250
           allocationStart: 172.20.1.10
           cidr: 172.20.1.0/24
           routes:
           - destination: 172.20.0.0/24
             nexthop: 172.20.1.1
           - destination: 172.20.2.0/24
             nexthop: 172.20.1.1
         vlan: 51
         attachConfiguration: br-osp
       - name: tenant_leaf2
         ipv4:
           allocationEnd: 172.20.2.250
           allocationStart: 172.20.2.10
           cidr: 172.20.2.0/24
           routes:
           - destination: 172.20.0.0/24
             nexthop: 172.20.2.1
           - destination: 172.20.1.0/24
             nexthop: 172.20.2.1
         vlan: 52
         attachConfiguration: br-osp

2. Create the internal API network:

   $ oc create -f openstacknetconfig.yaml -n openstack

Verification

1. View the resources and child resources for OpenStackNetConfig:

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

Procedure

1. Update the roles_data.yaml file:

   ...
   ###############################################################################
   # Role: ComputeLeaf1                                                          #
   ###############################################################################
   - name: ComputeLeaf1
     description: |
       Basic ComputeLeaf1 Node role
     # Create external Neutron bridge (unset if using ML2/OVS without DVR)
     tags:
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_leaf1
       Tenant:
         subnet: tenant_leaf1
       Storage:
         subnet: storage_leaf1
     HostnameFormatDefault: '%stackname%-novacompute-leaf1-%index%'
   ...
   ###############################################################################
   # Role: ComputeLeaf2                                                          #
   ###############################################################################
   - name: ComputeLeaf2
     description: |
       Basic ComputeLeaf1 Node role
     # Create external Neutron bridge (unset if using ML2/OVS without DVR)
     tags:
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_leaf2
       Tenant:
         subnet: tenant_leaf2
       Storage:
         subnet: storage_leaf2
     HostnameFormatDefault: '%stackname%-novacompute-leaf2-%index%'
   ...

2. In the ~/custom_environment_files directory, archive the templates into a tarball:

   $ tar -cvzf custom-config.tar.gz *.yaml

3. Create the tripleo-tarball-config ConfigMap:

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

Procedure

1. Create the OpenStackBackupRequest CRD and set the mode to save to request a backup:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBackupRequest
   metadata:
     name: openstackbackupsave
     namespace: openstack
   spec:
     mode: save
     additionalConfigMaps: []
     additionalSecrets: []

2. Optional: Use the additionalConfigMaps and additionalSecrets specifications to include ConfigMaps or Secrets that you created manually.

3. Monitor the status of the OpenStackBackupRequest:

   $ oc get -n openstack osbackuprequest openstackbackupsave
   NAME                     OPERATION   SOURCE   STATUS      COMPLETION TIMESTAMP
   openstackbackupsave      save                 Quiescing

   Note

   The Quiescing state indicates that director Operator is waiting for the CRs to reach their finished state. The length of time for the backup to finish can vary depending on the number of CRs.

4. You can investigate the director Operator logs to check progress:

   $ oc logs <operator_pod> -c manager -f
   2022-01-11T18:26:15.180Z        INFO    controllers.OpenStackBackupRequest      Quiesce for save for OpenStackBackupRequest openstackbackupsave is waiting for: [OpenStackBaremetalSet: compute, OpenStackControlPlane: overcloud, OpenStackVMSet: controller]

   • Replace <operator_pod> with the name of the Operator pod.

Verification

1. View the OpenStackBackupRequest to confirm that the STATUS is Saved:

   $ oc get -n openstack osbackuprequest
   NAME                     OPERATION   SOURCE   STATUS   COMPLETION TIMESTAMP
   openstackbackupsave      save                 Saved    2022-01-11T19:12:58Z

2. If the OpenStackBackupRequest enters the Error state, review the request contents to find the error:

   $ oc get -n openstack openstackbackuprequest <request_name> -o yaml

   • Replace <request_name> with the name of the backup request.

3. View the OpenStackBackup to confirm it exists:

   $ oc get -n openstack osbackup
   
   NAME                                AGE
   openstackbackupsave-1641928378      6m7s

Procedure

1. List the available backups:

   $ oc get osbackup

   Note

   To inspect the details of a specific backup:

   $ oc get backup <name> -o yaml

   • Replace <name> with the name of the backup you want to inspect.

2. Create the OpenStackBackupRequest CRD and set the mode to restore. For example:

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBackupRequest
   metadata:
     name: openstackbackupsave
     namespace: openstack
   spec:
     mode: <mode>
     restoreSource: <restore_source>

   • Replace <mode> with one of the following options:

     • restore - to request a restore from an existing OpenStackBackup.
     • cleanRestore - to completely wipe the existing director Operator resources within the namespace before any restoration attempt.
   • Replace <restore_source> with the ID of the OpenStackBackup to restore, for example, openstackbackupsave-1641928378.

3. Monitor the status of the OpenStackBackupRequest:

   $ oc get -n openstack osbackuprequest openstackbackuprestore
   NAME                     OPERATION  SOURCE                           STATUS     COMPLETION TIMESTAMP
   openstackbackuprestore   restore    openstackbackupsave-1641928378   Loading

   After all resources are loaded, director Operator begins reconciling:

   $ oc get -n openstack osbackuprequest openstackbackuprestore
   NAME                     OPERATION  SOURCE                           STATUS       COMPLETION TIMESTAMP
   openstackbackuprestore   restore    openstackbackupsave-1641928378   Reconciling

   Note

   If the OpenStackBackupRequest enters the Error state, view the request contents to find the error:

   $ oc get -n openstack openstackbackuprequest <name> -o yaml

Verification

1. View the OpenStackBackupRequest to confirm that the STATUS is Restored:

   $ oc get -n openstack osbackuprequest
   NAME                     OPERATION  SOURCE                           STATUS     COMPLETION TIMESTAMP
   openstackbackuprestore   restore    openstackbackupsave-1641928378   Restored   2022-01-12T13:48:57Z

Procedure

1. Change the number of Controller virtualMachineRole cores to 8:

   $ oc patch -n openstack osctlplane overcloud --type='json' -p='[{"op": "add", "path": "/spec/virtualMachineRoles/controller/cores", "value": 8 }]'

2. Change the Controller virtualMachineRole RAM size to 22GB:

   $ oc patch -n openstack osctlplane overcloud --type='json' -p='[{"op": "add", "path": "/spec/virtualMachineRoles/controller/memory", "value": 22 }]'

3. Validate the virtualMachineRole resource:

   $ oc get osvmset
   NAME         CORES   RAM   DESIRED   READY   STATUS        REASON
   controller   8       22    1         1       Provisioned   All requested VirtualMachines have been provisioned

4. From inside the virtual machine do a graceful shutdown. Shutdown each updated virtual machine one by one.

5. Power on the virtual machine:

   $ `virtctl start <VM>` to power on the virtual machine.

   • Replace <VM> with the name of your virtual machine.

Procedure

1. Add or update the additionalDisks parameter in the OpenStackControlPlane object:

   spec:
     ...
     virtualMachineRoles:
       Controller:
         ...
         additionalDisks:
         - baseImageVolumeName: openstack-base-img
           dedicatedIOThread: false
           diskSize: 10
           name: "data-disk1"
           storageAccessMode: ReadWriteMany
           storageClass: host-nfs-storageclass
           storageVolumeMode: Filesystem

2. Apply the patch:

   $ oc patch -n openstack osctlplane overcloud --patch-file controller_add_data_disk1.yaml

3. Validate the virtualMachineRole resource:

   $ oc get osvmset controller -o json | jq .spec.additionalDisks
   [
     {
       "baseImageVolumeName": "openstack-base-img",
       "dedicatedIOThread": false,
       "diskSize": 10,
       "name": "data-disk1",
       "storageAccessMode": "ReadWriteMany",
       "storageClass": "host-nfs-storageclass",
       "storageVolumeMode": "Filesystem"
     }
   ]

4. From inside the virtual machine do a graceful shutdown. Shutdown each updated virtual machine one by one.

5. Power on the virtual machine:

   $ `virtctl start <VM>` to power on the virtual machine.

   • Replace <VM> with the name of your virtual machine.

Procedure

1. Create the openstack namespace:

   $ oc new-project openstack

2. Create the index image and push it to your registry:

   $ podman login registry.redhat.io
   $ podman login your.registry.local
   $ BUNDLE_IMG="registry.redhat.io/rhosp-rhel8/osp-director-operator-bundle@sha256:c19099ac3340d364307a43e0ae2be949a588fefe8fcb17663049342e7587f055"

   Note

   You can get the latest bundle image from: Certified container images. Search for osp-director-operator-bundle.

3. Mirror the relevant images based on the operator index image:

   $ oc adm catalog mirror ${INDEX_IMG} your.registry.local --insecure --index-filter-by-os='Linux/x86_64'

4. After mirroring is complete, a manifests directory is generated in your current directory called manifests-osp-director-operator-index-<random_number>. Apply the created ImageContentSourcePolicy to your cluster:

   $ os apply -f manifests-osp-director-operator-index-<random_number>/imageContentSourcePolicy.yaml

   • Replace <random_number> with the randomly generated number.

5. Create a file named osp-director-operator.yaml and include the following YAML content to configure the three resources required to install director Operator:

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: osp-director-operator-index
     namespace: openstack
   spec:
     sourceType: grpc
     image: your.registry.local/osp-director-operator-index:1.3.x-y
   ---
   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

6. Create the new resources in the openstack namespace:

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

7. Copy the required overcloud images to the respository:

   $ for i in $(podman search --limit 1000 "registry.redhat.io/rhosp-rhel8/openstack" --format="{{ .Name }}" | awk '{print $1 ":" "16.2.4"}' | awk -F "/" '{print $2 "/" $3}'); do skopeo copy --all docker://registry.redhat.io/$i docker://your.registry.local/$i;done

   Note

   You can refer to Preparing a Satellite server for container images if Red Hat Satellite is used as the local registry.

8. You can now proceed with Preparing the overcloud deployment with the director Operator.

Verification

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

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