OpenStack Kolla Ansible and Swift: it’s over — a reminder on deploying it in legacy versions

It's official, Swift deployment is dropped in the Flamingo releases:

swift deployment support has been deprecated for removal in 2025.2 due to failing CI and no volunteers to maintain this role.

The deprecation was made official with this PR, merged on March 24, 2025: https://review.opendev.org/c/openstack/kolla-ansible/+/945113

Not surprising, really... I love Swift with all my heart... but it’s adoption has slowed down compared to Ceph (RADOS Gateway), especially in containerized environments. Maintaining Swift support in Kolla Ansible became increasingly difficult due to its aging architecture, lack of active contributors, and the complexity of deploying a stateful service with ring-based design.

How to bootstrap your disks before deploying — now legacy edition

I just wanted to make a quick post centralizing the old-school method for anyone deploying an older OpenStack release under a Kolla Ansible version that still supports Swift.

The process is documented here, so I can't say I'm bringing anything new this time. But I wanted to make sure it remains easily accessible: it’s a critical piece for anyone still relying on Swift through Kolla Ansible.

Disclaimer

If you’re deploying to production, I strongly recommend against using a now-unsupported feature like this. Instead, use Ceph if possible or deploy Swift outside of Kolla, and integrate it manually

Format your disks

You need to format your disk and add the KOLLA_SWIFT_DATA label for Kolla to detect theses disks as free for bootstrapping.

A standard dedicated storage node will often have between 36 to 48 disks per node ( sda to sdz then sdaa, sdab and so on). Here's a quick snippet on how to loop through all of them, excluding sda and sdb assuming they're you system disks (just remove the grep -Ev if you run on nvme, the system disks will be dev/nvmeX):

#/bin/bash

# excluding system disks sda and sdb
DISKS=$(lsblk -dno NAME | grep -E '^sd' | grep -Ev '^sda$|^sdb$' | sort)

# in case of nmve
#DISKS=$(lsblk -dno NAME | grep -E '^sd' | sort)

index=0
for d in $DISKS; do
    echo "Formatting /dev/${d} → label: d${index}"
    parted /dev/${d} -s -- mklabel gpt mkpart KOLLA_SWIFT_DATA 1 -1
    sudo mkfs.xfs -f -L d${index} /dev/${d}1
    (( index++ ))
done

If you have a small number of disk, a virtualized lab environment with 3 storage disks, in this example sdc and sdd and sde, just execute:

index=0
for d in sdc sdd sde; do
    parted /dev/${d} -s -- mklabel gpt mkpart KOLLA_SWIFT_DATA 1 -1
    sudo mkfs.xfs -f -L d${index} /dev/${d}1
    (( index++ ))
done

Prepare the rings

Now you need to prepare the different rings, object, account and container.

Export these environment variables, containing the list of your hosts:

STORAGE_NODES=(192.168.0.2 192.168.0.3 192.168.0.4)
KOLLA_SWIFT_BASE_IMAGE="kolla/centos-source-swift-base:4.0.0"

Then create the /etc/kolla/config/swift directory, which will contain your ring files:

mkdir -p /etc/kolla/config/swift

Object

Create the ring:

docker run \
  --rm \
  -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
  swift-ring-builder \
    /etc/kolla/config/swift/object.builder create 10 3 1

Add the devices:

for node in ${STORAGE_NODES[@]}; do
    for i in {0..2}; do
      docker run \
        --rm \
        -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
        swift-ring-builder \
          /etc/kolla/config/swift/object.builder add r1z1-${node}:6000/d${i} 1;
    done
done

Account

Create the ring:

docker run \
  --rm \
  -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
  swift-ring-builder \
    /etc/kolla/config/swift/account.builder create 10 3 1

Add the devices:

for node in ${STORAGE_NODES[@]}; do
    for i in {0..2}; do
      docker run \
        --rm \
        -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
        swift-ring-builder \
          /etc/kolla/config/swift/account.builder add r1z1-${node}:6001/d${i} 1;
    done
done

Container

Create the ring:

docker run \
  --rm \
  -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
  swift-ring-builder \
    /etc/kolla/config/swift/container.builder create 10 3 1

Add the devices:

for node in ${STORAGE_NODES[@]}; do
    for i in {0..2}; do
      docker run \
        --rm \
        -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
        swift-ring-builder \
          /etc/kolla/config/swift/container.builder add r1z1-${node}:6002/d${i} 1;
    done
done

Rebalance

for ring in object account container; do
  docker run \
    --rm \
    -v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
KOLLA_SWIFT_BASE_IMAGE \
    swift-ring-builder \
      /etc/kolla/config/swift/${ring}.builder rebalance;
done

Multiple policies

If you have multiple policy (= multiple ring), you need to override the swift_extra_ring_files variable:

swift_extra_ring_files:
   - object-1.builder
   - object-1.ring.gz
   - object-2.builder
   - object-2.ring.gz

Deploy

Don't forget to set your variables accordingly in your configuration file, the most important one being:

enable_swift: "yes"

Example grep output of the globals.yml for reference:

$ grep -i swift globals.yml
#swift_storage_interface: "{{ network_interface }}"
#swift_replication_interface: "{{ swift_storage_interface }}"
#swift_storage_address_family: "{{ storage_address_family }}"
#swift_replication_address_family: "{{ swift_storage_address_family }}"
#enable_swift: "no"
#enable_swift_s3api: "no"
#glance_backend_swift: "no"
# Valid options are [ file, ceph, swift ]
#gnocchi_backend_storage: "{% if enable_swift | bool %}swift{% else %}file{% endif %}"
# Valid options are [ nfs, swift, ceph, s3 ]
# Swift - Object Storage Options
# Swift expects block devices to be available for storage. Two types of storage
# is used to detect the disk which Swift will be using.
# Swift support two matching modes, valid options are [ prefix, strict ]
#swift_devices_match_mode: "strict"
# for swift_devices_match_mode then swift_device_name should specify the name of
# the special swift partition for example: "KOLLA_SWIFT_DATA", if "prefix" mode was
# selected then swift_devices_name should specify a pattern which would match to
# filesystems' labels prepared for swift.
#swift_devices_name: "KOLLA_SWIFT_DATA"
# Configure swift upgrade option, due to currently kolla support
# two upgrade ways for swift: legacy_upgrade and rolling_upgrade
# The variable "swift_enable_rolling_upgrade: yes" is meaning rolling_upgrade
#swift_enable_rolling_upgrade: "yes"

Then you can deploy:

 kolla-ansible deploy -i inventory

What's next?

I’ll probably continue using Kolla Ansible to deploy Swift in lab or testing environments for a while: it’s still an easy and straightforward way to spin up a fully working (and containerized) Swift setup, whether it’s an all-in-one or multinode deployment.

I don’t think there are many legit use cases left for deploying Swift this way anymore, so I'm not gonna work on a step by step guide on how to integrate an external Swift cluster with a Kolla Ansible deployment... unless...