/swift

name: openstack-swift
description: "OpenStack Swift object storage service. Provides S3-compatible distributed object storage with containers, ACLs, ring architecture, eventual consistency, large object support (SLO/DLO), tempURL for unauthenticated access, object versioning, and object expiry. Use for deploying, configuring, operating, and troubleshooting OpenStack object storage."
user-invocable: true
allowed-tools: Read Grep Glob
metadata:
  extensions:
    gsd-skill-creator:
      version: 1
      createdAt: "2026-02-23"
      triggers:
        intents:
          - "swift"
          - "object storage"
          - "container"
          - "s3 compatible"
          - "large object"
          - "ring"
          - "ACL"
          - "tempurl"
        contexts:
          - "deploying openstack object storage"
          - "managing swift containers"
          - "troubleshooting object storage"
          - "configuring s3 compatibility"

OpenStack Swift -- Object Storage Service

Swift provides distributed object storage with an HTTP-accessible API. Unlike block storage (Cinder), which provides attached devices, Swift stores objects (files) in containers (buckets) accessible via REST API calls. Swift is S3-compatible when the `s3api` middleware is enabled, making it a drop-in replacement for AWS S3 in many applications.

Architecture

Swift uses a **ring architecture** to determine where objects are stored. Even in a single-node deployment, understanding rings is important because they control data placement and replication.

• **Rings:** Swift maintains three rings -- account, container, and object. Each ring maps a partition to a set of devices (disks). The ring builder calculates this mapping based on the number of replicas, partition power, and device weights.
• **Partition power:** Determines how many partitions exist (2^power). Higher partition power = more granular distribution but more memory usage. Single-node typically uses partition power 10 (1024 partitions).
• **Replicas:** The number of copies of each object. Production uses 3 replicas across failure zones. Single-node uses 1 replica (no redundancy benefit with one node).
• **Eventual consistency:** Swift is designed around eventual consistency. After a write, reads from different nodes may temporarily return different results. Replicator and auditor processes converge state over time.

**Service components:**

• `swift-proxy`: The API frontend. Receives HTTP requests, authenticates via Keystone, routes requests to the appropriate storage nodes using the rings.
• `swift-account`: Manages account-level metadata and container listings.
• `swift-container`: Manages container-level metadata and object listings.
• `swift-object`: Stores and retrieves actual object data on disk.
• Auxiliary services: `object-replicator`, `object-auditor`, `container-updater`, `account-reaper` (background consistency processes).

Deploy

Kolla-Ansible Configuration

Key settings in `globals.yml`:

# Enable Swift
enable_swift: "yes"

# Disk configuration for Swift storage
# Kolla-Ansible expects dedicated disks or partitions
# Format: label:device pairs
swift_devices_name: "KOLLA_SWIFT_DATA"

# Number of replicas (1 for single-node)
swift_default_replication_count: 1

Disk Setup for Swift

Swift requires dedicated storage devices. For Kolla-Ansible:

# Format and label a disk for Swift
parted /dev/sdc mklabel gpt
parted /dev/sdc mkpart primary xfs 0% 100%
mkfs.xfs -f /dev/sdc1
# Label must match swift_devices_name
xfs_admin -L KOLLA_SWIFT_DATA /dev/sdc1

# Alternatively, use a loop device for testing
dd if=/dev/zero of=/srv/swift-disk bs=1M count=10240
mkfs.xfs -f /srv/swift-disk
# Mount and label for Kolla-Ansible discovery

Ring Building (Single-Node)

Kolla-Ansible builds rings during deployment. For single-node with 1 replica:

# Kolla-Ansible handles ring building, but for manual ring management:
# Account ring
swift-ring-builder account.builder create 10 1 1
swift-ring-builder account.builder add --region 1 --zone 1 \
  --ip 10.0.0.1 --port 6202 --device sdc1 --weight 100
swift-ring-builder account.builder rebalance

# Container ring (same pattern)
swift-ring-builder container.builder create 10 1 1
swift-ring-builder container.builder add --region 1 --zone 1 \
  --ip 10.0.0.1 --port 6201 --device sdc1 --weight 100
swift-ring-builder container.builder rebalance

# Object ring (same pattern)
swift-ring-builder object.builder create 10 1 1
swift-ring-builder object.builder add --region 1 --zone 1 \
  --ip 10.0.0.1 --port 6200 --device sdc1 --weight 100
swift-ring-builder object.builder rebalance

Container and Service Verification

# List Swift containers
docker ps --format '{{.Names}}' | grep swift

# Expected containers:
# swift_proxy_server, swift_account_server, swift_container_server,
# swift_object_server, swift_account_reaper, swift_object_expirer,
# swift_rsyncd

# Verify Swift is operational
openstack object store account show
# Should return account info with container count and bytes used

# Check S3 API availability (if s3api middleware is enabled)
# Use AWS CLI or s3cmd with OpenStack credentials

Configure

Storage Policies

Storage policies define different tiers of storage with different replication counts, erasure coding parameters, or device assignments.

# In swift.conf (through Kolla-Ansible config override)
[storage-policy:0]
name = standard
default = yes

# Additional policies for different tiers:
# [storage-policy:1]
# name = high-durability
# (requires separate ring and additional devices)

S3 API Middleware

Swift's `s3api` middleware provides S3-compatible API access:

# In proxy-server.conf pipeline (Kolla-Ansible configures this when enabled)
# pipeline = ... s3api s3token keystoneauth ... proxy-server

Using the S3 API:

# Create EC2 credentials for S3 access
openstack ec2 credentials create

# Use with