Extended Storage Backend Prerequisites¶

Ensure that the following prerequisites are met before you configure an ESB for StarlingX OpenStack.

This section covers the following topics:

Cinder Driver Support ¶

Verify that your storage array’s Cinder driver is included in the upstream OpenStack cinder package for the 2026.1 (Gazpacho) release. Drivers that require vendor-supplied libraries or custom container images are not supported in this release.

See the Cinder driver support matrix.

Storage Array Preparation ¶

Before applying the application, configure the storage array and ensure that its management API is accessible from the controller nodes.

For iscsi and fcp backends, configure targets or zoning and verify connectivity from the compute nodes.
For nfs backends, create the required exports and verify that they can be mounted.

Kubernetes StorageClass ¶

Determine whether the backend requires a Kubernetes StorageClass.

A backend used for Cinder volumes (typically iscsi or fcp) can use k8s_storage_class: none to access the storage array directly.
A backend that also provisions Kubernetes PVC storage for the control plane, Glance, or Nova requires a valid StorageClass backed by an installed and operational CSI driver. StarlingX OpenStack does not install CSI drivers.

Confirm which StorageClasses exist by running the following command:

~(keystone_admin)]$ kubectl get storageclass

Note

StarlingX OpenStack does not validate the StorageClass specified in k8s_storage_class before applying the application. Ensure that the StorageClass name is correct and its associated CSI driver is operational.

Credentials Secret ¶

If the backend requires credentials, create a Kubernetes Secret containing the storage array’s management credentials used by the Cinder driver to authenticate with the array. These credentials are typically different from your platform login credentials. Using your platform login instead will cause authentication to fail and prevent the backend from starting.

~(keystone_admin)]$ kubectl create secret generic <secret-name> \
                    --namespace openstack \
                    --from-literal=<key1>=<value1> \
                    --from-literal=<key2>=<value2>

Reference the Secret in the backend’s secretRef and map each Secret key to the cinder.conf field required by the driver. A single Secret can hold the credentials for several backends, each mapping the keys it needs.

Note

The openstack namespace exists only after StarlingX OpenStack has been applied at least once. On a first-time installation, create the openstack namespace manually before creating the Secret. The Secret must exist before you apply StarlingX OpenStack.

TLS Certificate for Array API ¶

If the array’s management API uses HTTPS with a private or self-signed CA, place the CA certificate on the active controller and point storage_conf.tls.host_cert at it. The default path is /var/opt/openstack/certs/storage.pem.

~(keystone_admin)]$ mkdir -p /var/opt/openstack/certs

The certificate file must exist at host_cert when you apply the application. If the path is incorrect, the apply operation still succeeds but no certificate is mounted and the TLS handshake fails at runtime.

Note

storage_conf.netapp_tls from the previous release is still supported and automatically mapped to storage_conf.tls. However, it is deprecated and planned for removal in a future release. Use storage_conf.tls for new configurations.

Control-Plane StorageClass Decision ¶

If you plan to place the control-plane services (MariaDB and RabbitMQ) on an extended backend, decide during first installation.

The PVCs for MariaDB and RabbitMQ are created once, and Kubernetes does not allow the StorageClass of an existing claim to change. Changing it on a running system causes the apply operation to fail while upgrading the MariaDB or RabbitMQ release. To move these services to a different StorageClass later, you must remove the application, delete the existing claims, and re-apply the application. See Configure an Extended Storage Backend.

Note

A VolumeSnapshotClass must be available before updating the application if MariaDB uses a PVC-backed extended backend. Create the VolumeSnapshotClass before initiating the application update.