Configure an External NetApp Storage Backend for OpenStack¶

About this task

This section describes the end-to-end process for deploying StarlingX OpenStack with NetApp as the storage backend, including configuring the appropriate NetApp storage type (FC, iSCSI, or NFS) for StarlingX installation, applying the required overrides for StarlingX OpenStack, and verifying core OpenStack services through storage operations in Glance, Nova, and Cinder.

Configure NetApp NFS-Based Storage ¶

Use this procedure for deploying StarlingX OpenStack with NetApp NFS as the storage backend for all OpenStack services.

Use this procedure as a baseline when configuring other NetApp storage types. Subsequent sections cover advanced configurations, detailed references for individual services, alternative storage types, and multi-protocol configurations.

Prerequisites

Ensure the NetApp prerequisites are met. For more information, see NetApp External Storage Prerequisites.
Replace the placeholder values in this section with the values specific to your environment:

Table 1. Placeholder Values for NetApp Storage Types¶
Placeholder	Description	Example value
<DATA_LIF>	NetApp NFS Data LIF address	[fd00:aa:bb:dd::3] or 192.168.2.10
<CINDER_VOL_SHARE>	NFS export for Cinder volumes	[fd00:aa:bb:dd::3]:/openstack_volumes
<CINDER_BACKUP_SHARE>	NFS export for Cinder backups	[fd00:aa:bb:dd::3]:/openstack_volumes_backups
<NOVA_NFS_SERVER> [1]	NFS server for Nova ephemeral	192.168.2.20
<NOVA_NFS_PATH>	NFS export path for Nova	/openstack_instances

Procedure

Create Helm YAML override files. Create five YAML files , one per Helm chart that needs NetApp configuration.

Each OpenStack service is configured through Helm chart user overrides. Create a YAML file with the desired overrides for each chart, then apply the overrides before deploying the StarlingX OpenStack application.

mariadb.yaml

storage_conf:
  volume_storage_class_priority:
    - netapp-nfs

rabbitmq.yaml

storage_conf:
  volume_storage_class_priority:
    - netapp-nfs

cinder.yaml

storage_conf:
  volume_storage_class_priority:
    - netapp-nfs
  backup_storage_class_priority:
    - netapp-nfs
conf:
  nfs_shares: |
    <CINDER_VOL_SHARE>
  cinder:
    DEFAULT:
      backup_share: "<CINDER_BACKUP_SHARE>"

glance.yaml

storage_conf:
  volume_storage_class_priority:
    - cinder

nova.yaml

storage_conf:
  volume_storage_class_priority:
    - nfs
  nfs_shares:
    server: "<NOVA_NFS_SERVER>"
    path: <NOVA_NFS_PATH>

Initialize the platform environment.
```
$ source /etc/platform/openrc
```

Apply overrides for infrastructure charts.

$ system helm-override-update --reuse-values --values mariadb.yaml StX-openstack mariadb openstack
$ system helm-override-update --reuse-values --values rabbitmq.yaml StX-openstack rabbitmq openstack

Apply overrides for OpenStack service charts.

$ system helm-override-update --reuse-values --values cinder.yaml StX-openstack cinder openstack
$ system helm-override-update --reuse-values --values glance.yaml StX-openstack glance openstack
$ system helm-override-update --reuse-values --values nova.yaml StX-openstack nova openstack

Use the --reuse-values option whenever you update chart overrides to preserve any previously configured values.

Verify each chart has the expected overrides.

$ system helm-override-show StX-openstack mariadb openstack
$ system helm-override-show StX-openstack rabbitmq openstack
$ system helm-override-show StX-openstack cinder openstack
$ system helm-override-show StX-openstack glance openstack
$ system helm-override-show StX-openstack nova openstack

Apply the StarlingX OpenStack application.
```
$ system application-apply StX-openstack
```
Verify application status.
```
$ system application-show StX-openstack
```
Confirm that the application status is applied.

Configure Other NetApp Storage Protocols ¶

Use the NFS-based baseline procedure in Configure NetApp NFS-Based Storage as a template when configuring NetApp iSCSI or FC storage.

When using the procedure for iSCSI or FC, apply the following changes:

Replace netapp-nfs with netapp-iscsi or netapp-fc in volume_storage_class_priority lists.
For Cinder configurations using iSCSI or FC:
- Remove the nfs_shares configuration field.
- Keep netapp-nfs selected at backup_storage_class_priority. Selecting netapp-fc|netapp-iscsi for Cinder backups will result in backups being stored into netapp-fc|netapp-iscsi PVC, which is supported but not recommended.

storage_conf:
  volume_storage_class_priority:
    - <netapp-iscsi|netapp-fc>
  backup_storage_class_priority:
    - netapp-nfs
conf:
  cinder:
    DEFAULT:
      backup_share: "<CINDER_BACKUP_SHARE>"

Review the Supported Storage Combinations table to confirm supported storage combinations.

For protocol-specific override examples and service-level details, refer to the individual configuration sections for Cinder, Glance, and Nova.

Verify NetApp Storage Configuration ¶

After deploying StarlingX OpenStack with NetApp NFS, verify that OpenStack services use NetApp as their storage backend.

Procedure

Verify infrastructure PVCs (MariaDB/RabbitMQ).
```
$ kubectl -n openstack get pvc | grep -E "mariadb|rabbitmq"
```
If any PVC remains in the PENDING state, see PVC Stuck in Pending State to troubleshoot the issue.
Verify Cinder backends.
```
$ openstack volume type list
$ openstack volume service list
```
Confirm that the NetApp backends (for example, netapp-nfs, netapp-iscsi, and netapp-fc) appear in the output and that all listed services are UP. If any of the services are DOWN, see Cinder Volume or Backup Pod Errors to troubleshoot the issue.

Test volume creation.

$ openstack volume create --size 1 --type netapp-nfs test-nfs-vol
$ openstack volume show test-nfs-vol

Verify that the volume status is available.

Test Cinder volume backup.

$ openstack volume backup create --name test-backup test-nfs-vol
$ openstack volume backup show test-backup

Verify the status is displayed as “available”.

Test Glance.

$ openstack image create --disk-format qcow2 --container-format bare \
  --file <IMAGE_FILE> test-image
openstack image show test-image

Verify the status is displayed as “active”.

Test Nova instance launch.

$ openstack server create --flavor <FLAVOR> --image test-image \
  --network <NETWORK> test-vm
openstack server show test-vm

Verify the status is displayed as “ACTIVE”.