Skip to content

Control plane configuration options for Red Hat OpenStack Platform (RHOSP)

You can update your control plane machines to reflect changes in your infrastructure or environment by editing values in the control plane machine set specification.

When you save an update to the control plane machine set, the Control Plane Machine Set Operator updates the control plane machines according to your configured update strategy. For more information, see "Updating the control plane configuration".

The following example YAML snippets show provider specification and failure domain configurations for an RHOSP cluster.

Sample RHOSP provider specification

You can update your control plane machines to reflect changes in your underlying infrastructure by editing values in the control plane machine set provider specification.

The following example YAML illustrates a valid configuration for an Red Hat OpenStack Platform (RHOSP) cluster.

Note

When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that the installation program creates.

You can omit any field that has a value set in the failure domain section of the CR.

In the following example, the <cluster_id> string is the infrastructure ID. The infrastructure ID matches the cluster ID that the installation program used during cluster provisioning. If you have the OpenShift CLI (oc) installed, you can obtain the infrastructure ID by running the following command:

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
Sample OpenStack providerSpec values
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            apiVersion: machine.openshift.io/v1alpha1
            cloudName: openstack
            cloudsSecret:
              name: openstack-cloud-credentials
              namespace: openshift-machine-api
            flavor: m1.xlarge
            image: <cluster_id>-rhcos
            kind: OpenstackProviderSpec
            metadata:
              creationTimestamp: null
            networks:
            - filter: {}
              subnets:
              - filter:
                  name: <cluster_id>-nodes
                  tags: openshiftClusterID=<cluster_id>
            securityGroups:
            - filter: {}
              name: <cluster_id>-master
            serverGroupName: <cluster_id>-master
            serverMetadata:
              Name: <cluster_id>-master
              openshiftClusterID: <cluster_id>
            tags:
            - openshiftClusterID=<cluster_id>
            trunk: true
            userDataSecret:
              name: master-user-data

where:

spec.template.spec.providerSpec.value.cloudsSecret.name

Specifies the secret name for the cluster. Do not change this value.

spec.template.spec.providerSpec.value.flavor

Specifies the RHOSP flavor type for the control plane.

spec.template.spec.providerSpec.value.kind

Specifies the cloud provider platform type. Do not change this value.

spec.template.spec.providerSpec.value.securityGroups

Specifies the control plane machines security group.

Sample RHOSP failure domain configuration

To prevent downtime for your application due to the failure of a single Red Hat OpenStack Platform (RHOSP) region, you can configure failure domains in the control plane machine set. To use failure domains, you configure appropriate values in the failureDomains section of the ControlPlaneMachineSet custom resource (CR).

The control plane machine set concept of a failure domain is analogous to the existing RHOSP concept of an availability zone. The ControlPlaneMachineSet CR spreads control plane machines across more than one failure domain when possible.

Sample OpenStack failure domain values
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    machines_v1beta1_machine_openshift_io:
      failureDomains:
        openstack:
        - availabilityZone: nova-az0
          rootVolume:
            availabilityZone: cinder-az0
        - availabilityZone: nova-az1
          rootVolume:
            availabilityZone: cinder-az1
        - availabilityZone: nova-az2
          rootVolume:
            availabilityZone: cinder-az2
        platform: OpenStack
# ...

where:

spec.template.machines_v1beta1_machine_openshift_io.failureDomains.openstack

Specifies the availability zones for the failure domains. This example demonstrates the use of more than one Nova availability zone and corresponding Cinder availability zones.

spec.template.machines_v1beta1_machine_openshift_io.failureDomains.platform

Specifies the cloud provider platform name. Do not change this value.

Additional resources