Chapter 7. Configuring the Object Storage service (swift)

Procedure

1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the swift template:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
     ...
     swift:
       enabled: true
       template:
         swiftProxy:
           replicas: 2
         swiftRing:
           ringReplicas: 3
         swiftStorage:
           replicas: 3
           storageClass: <swift-storage>
           storageRequest: 100Gi
   ...

   • Increase the swiftProxy/replicas: value to distribute proxy instances across more nodes.
   • Replace the ringReplicas: value to define the number of object copies you want in your cluster.
   • Increase the swiftStorage/replicas: value to define the number of PVs in your cluster.
   • Replace <swift-storage> with the name of the storage class you want the Object Storage service to use.

2. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml -n openstack

3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status:

   $ oc get openstackcontrolplane -n openstack

   The OpenStackControlPlane resources are created when the status is "Setup complete".

   Tip

   Append the -w option to the end of the get command to track deployment progress.

Procedure

1. Enable DNS forwarding to resolve data plane hostnames in the control plane pods.

   1. Obtain the clusterIP of the resolver:

      $ oc get svc dnsmasq-dns -o jsonpath=`{.spec.clusterIP}`

   2. Update the default DNS entry to add the clusterIP of the resolver:

      apiVersion: operator.openshift.io/v1
      kind: DNS
      metadata:
        name: default
      spec:
        servers:
        - name: swift
          zones:
          - storage.example.com
          forwardPlugin:
            policy: Random
            upstreams:
            - <clusterIP>

      • Replace <clusterIP> with the clusterIP of the resolver.

2. Enable the swift storage service on the data plane nodes by adding the swift service to the end of the list of services for the NodeSet in your OpenStackDataPlaneNodeSet CR. The service runs the playbooks that are required to configure the Object Storage services:

   Example:

       services:
       - repo-setup
       - bootstrap
       - download-cache
       - configure-network
       - validate-network
       - install-os
       - configure-os
       - ssh-known-hosts
       - run-os
       - reboot-os
       - install-certs
       - swift

3. Define disks to be used by the Object Storage service on data plane nodes.

   • When you define disks, you can do the following:

     • Define the disks in the global nodeTemplate section in your OpenStackDataPlaneNodeSet CR to use the same type of disks for all nodes.
     • Define disks on a per-node basis in the nodes section of your OpenStackDataPlaneNodeSet CR.
     • Assign disks to a specific region or zone.
     • Enable ring management to distribute replicas.

   • You must specify a weight for each disk. If you do not have custom weights in your existing rings, you can set the weight to the GiB capacity of the disk.

     The following example shows the OpenStackDataPlaneNodeSet CR for a data plane with three storage nodes. Each node is configured to use two disks in the nodeTemplate section. The first node edpm-swift-0 is configured to use a third disk in the nodes section:

     Example:

     - apiVersion: dataplane.openstack.org/v1beta1
       kind: OpenStackDataPlaneNodeSet
       metadata:
         name: openstack-edpm-ipam
         namespace: openstack
       spec:
         ...
         networkAttachments:
         - ctlplane
         - storage
         nodeTemplate:
           ansible:
             ansibleVars:
               edpm_swift_disks:
               - device: /dev/vdb
                 path: /srv/node/vdb
                 region: 0
                 weight: 4000
                 zone: 0
               - device: /dev/vdc
                 path: /srv/node/vdc
                 region: 0
                 weight: 4000
                 zone: 0
         nodes:
           edpm-swift-0:
             ansible:
               ansibleVars:
                 edpm_swift_disks:
                 - device: /dev/vdd
                   path: /srv/node/vdd
                   weight: 1000
             hostName: edpm-swift-0
             networks:
             - defaultRoute: true
               fixedIP: 192.168.122.100
               name: ctlplane
               subnetName: subnet1
             - name: internalapi
               subnetName: subnet1
             - name: storage
               subnetName: subnet1
             - name: tenant
               subnetName: subnet1
           edpm-swift-1:
             hostName: edpm-swift-1
             networks:
             - defaultRoute: true
               fixedIP: 192.168.122.101
               name: ctlplane
               subnetName: subnet1
             - name: internalapi
               subnetName: subnet1
             - name: storage
               subnetName: subnet1
             - name: tenant
               subnetName: subnet1
           edpm-swift-2:
             hostName: edpm-swift-2
             networks:
             - defaultRoute: true
               fixedIP: 192.168.122.102
               name: ctlplane
               subnetName: subnet1
             - name: internalapi
               subnetName: subnet1
             - name: storage
               subnetName: subnet1
             - name: tenant
               subnetName: subnet1
         ...
         services:
         - repo-setup
         - bootstrap
         - download-cache
         - configure-network
         - validate-network
         - install-os
         - configure-os
         - ssh-known-hosts
         - run-os
         - reboot-os
         - install-certs
         - swift

Procedure

1. Manually trigger a ring rebalance:

   Important

   Only rebalance after any previous rebalance is fully replicated. Rebalancing before replication has completed can cause data to be moved multiple times, increasing the risk of temporary data unavailability.

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-tool rebalance'

   This rebalances all Object Storage rings and updates the ring files in the swift-ring-files ConfigMap.

2. If you use external data plane nodes, push the updated rings to the data plane nodes. Delete any previous ring update deployment and create a new OpenStackDataPlaneDeployment CR that runs only the swift service with the swiftrings Ansible tag. This distributes the updated ring files to all data plane nodes without running a full deployment:

   $ oc delete --ignore-not-found --wait openstackdataplanedeployment swift-ring-update -n openstack
   $ oc apply -n openstack -f - << EOF
   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: swift-ring-update
   spec:
     ansibleTags: swiftrings
     servicesOverride:
       - swift
     nodeSets:
       - <nodeset_name>
   EOF

   • Replace <nodeset_name> with the name of your OpenStackDataPlaneNodeSet CR.

3. Wait for the deployment to complete:

   $ oc wait openstackdataplanedeployment swift-ring-update --for condition=Ready --timeout=300s -n openstack

4. Verify cluster health by checking that all rings are consistent and replication is progressing:

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-recon -rT --md5'

   • Verify that all ring md5sums are consistent across nodes.
   • Check the replication timestamps. The oldest completion time minus the highest replication time gives you the earliest start time of the last replication pass. This earliest start time must be after the ring ConfigMaps have been updated, confirming that all nodes have completed a full replication pass with the new rings.

5. Alternatively, you can check the object-replicator logs directly to verify that a full replication pass has completed:

   $ oc logs --timestamps -l component=swift-storage -c object-replicator --tail 1000 | grep replicated

   Look for log entries that show the completion of a replication pass, for example:

   $ oc logs --timestamps -c object-replicator swift-storage-0
   2026-04-02T10:44:13.863401909Z object-replicator: Object replication complete.  (33.00 minutes)

   The completion timestamp minus the duration gives you the start time of the pass. For example, a completion at 10:44:13 with a duration of 33.00 minutes means the pass started at 10:11:13. This start time must be after the ring ConfigMaps were updated. If the pass started before the ConfigMap update, it was still using the old rings and you must wait for the next full pass to complete.

6. Run swift-dispersion-report to verify that all replicas have been placed correctly:

   $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-report'

   The output shows the percentage of objects and containers with all replicas found. All values must be at 100% before you perform another rebalance.

Procedure

1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and change the value for partPower under the swiftRing parameter in the swift template:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
     ...
     swift:
       enabled: true
       template:
         swiftProxy:
           replicas: 2
         swiftRing:
           partPower: 12
           ringReplicas: 3
   ...

   • Replace <12> with the value you want to set for partition power.

     Tip

     You can also configure an additional object server ring for new containers. This is useful if you want to add more disks to an Object Storage service deployment that initially uses a low partition power.