Juju Charm - Swift proxy
Go to file
Corey Bryant 4ebb43d731 Enable swift payload upgrades for wallaby+
Sync charm-helpers to pick up fix for openstack_upgrade_available
that enables successful payload upgrades. This will need backporting
to stable/wallaby.

Closes-Bug: #2040606
Change-Id: Ib5f446d617c11c9c9046c33335c1099b21b5166e
2023-10-26 08:10:43 -04:00
actions Fix yaml safe_load and allow unittests on py35 2021-10-14 14:32:00 +01:00
charmhelpers Enable swift payload upgrades for wallaby+ 2023-10-26 08:10:43 -04:00
files Sync charm/ceph helpers, tox, and requirements 2019-10-01 14:38:02 -05:00
hooks Use python3-jinja2 for py3. 2022-04-21 17:36:50 -04:00
lib Add support for HAProxy L7 checks 2023-02-23 21:07:47 -03:00
scripts - removed health checks 2013-04-05 17:34:01 -04:00
swift_manager Use unittest.mock instead of mock 2021-12-15 11:45:01 +00:00
templates Add Kinetic and Zed support 2022-09-06 16:23:07 +00:00
tests Add 2023.2 Bobcat support 2023-07-24 17:38:23 -04:00
unit_tests Improve platform mocking 2023-10-24 16:15:39 +01:00
.gitignore Migrate charm to charmhub latest/edge track 2022-02-24 10:26:12 +00:00
.gitreview OpenDev Migration Patch 2019-04-19 19:36:59 +00:00
.project Fixup missing files 2013-02-27 16:18:34 +00:00
.pydevproject Enable xenial/queens amulet tests 2018-03-20 09:54:11 +00:00
.stestr.conf Convert charm to Python 3 only 2017-12-06 14:20:25 +00:00
.zuul.yaml Add Antelope support 2023-03-08 12:47:59 +00:00
LICENSE Re-license charm as Apache-2.0 2016-07-01 18:12:11 +01:00
Makefile Sync helpers for 20.05 2020-05-18 14:50:24 +02:00
README.Swift_ring_management Fix typo in ring management README 2019-05-17 11:19:47 -07:00
README.md Trivial grammar fix in README.md 2022-06-17 12:25:11 +05:45
actions.yaml Drop support of swauth for Train and later 2020-01-07 15:03:08 -05:00
bindep.txt Add Kinetic and Zed support 2022-09-06 16:23:07 +00:00
build-requirements.txt Migrate charm to charmhub latest/edge track 2022-02-24 10:26:12 +00:00
charm-helpers-hooks.yaml charmhelpers sync for yoga release 2022-04-07 12:30:36 +01:00
charmcraft.yaml Add 2023.2 Bobcat support 2023-07-24 17:38:23 -04:00
config.yaml Add 2023.2 Bobcat support 2023-07-24 17:38:23 -04:00
copyright Re-license charm as Apache-2.0 2016-07-01 18:12:11 +01:00
hardening.yaml Add hardening support 2016-03-24 11:36:26 +00:00
icon.svg Update charm icon 2017-08-02 17:28:33 +01:00
metadata.yaml Add 2023.2 Bobcat support 2023-07-24 17:38:23 -04:00
osci.yaml Add 2023.2 Bobcat support 2023-07-24 17:38:23 -04:00
rename.sh Migrate charm to charmhub latest/edge track 2022-02-24 10:26:12 +00:00
requirements.txt Add Kinetic and Zed support 2022-09-06 16:23:07 +00:00
revision Add config options for proxy-server.conf template. node-timeout and recoverable-node-timeout. For large swift/glance uploads, higher defaults are needed to prevent uploads from failing on real servers which are slower than VMs. 2014-06-03 20:38:25 -05:00
setup.cfg [ussuri][goal] Updates for python 2.7 drop 2020-03-24 17:03:44 +00:00
test-requirements.txt Fix charm for tox4 compatibility 2023-01-18 12:57:17 +00:00
tox.ini Add support for HAProxy L7 checks 2023-02-23 21:07:47 -03:00



OpenStack Swift is a highly available, distributed, eventually consistent object/blob store.

The swift-proxy charm deploys Swift's proxy component. The charm's basic function is to manage zone assignment and enforce replica requirements for the storage nodes. It works in tandem with the swift-storage charm, which is used to add storage nodes.



This section covers common configuration options. See file config.yaml for the full list of options, along with their descriptions and default values.


The zone-assignment option defines the zone assignment method for storage nodes. Values include 'manual' (the default) and 'auto'.


The replicas option stipulates the number of data replicas that are needed. This value should be equal to the number of zones. The default value is '3'.


Let file swift.yaml contain the deployment configuration:

        zone-assignment: manual
        replicas: 3
        zone: 1
        block-device: /dev/sdb
        zone: 2
        block-device: /dev/sdb
        zone: 3
        block-device: /dev/sdb

Deploy the proxy and storage nodes:

juju deploy --config swift.yaml swift-proxy
juju deploy --config swift.yaml swift-storage swift-storage-zone1
juju deploy --config swift.yaml swift-storage swift-storage-zone2
juju deploy --config swift.yaml swift-storage swift-storage-zone3

Add relations between the proxy node and all storage nodes:

juju add-relation swift-proxy:swift-storage swift-storage-zone1:swift-storage
juju add-relation swift-proxy:swift-storage swift-storage-zone2:swift-storage
juju add-relation swift-proxy:swift-storage swift-storage-zone3:swift-storage

This will result in a three-zone cluster, with each zone consisting of a single storage node, thereby satisfying the replica requirement of three.

Storage capacity is increased by adding swift-storage units to a zone. For example, to add two storage nodes to zone '3':

juju add-unit -n 2 swift-storage-zone3

Note: When scaling out ensure the candidate machines are equipped with the block devices currently configured for the associated application.

This charm will not balance the storage ring until there are enough storage zones to meet its minimum replica requirement, in this case three.

Appendix Swift usage in the OpenStack Charms Deployment Guide offers in-depth guidance for deploying Swift with charms. In particular, it shows how to set up a multi-region (global) cluster.

Swift as backend for Glance

Swift may be used as a storage backend for the Glance image service. To do so, add a relation between the swift-proxy and glance applications:

juju add-relation swift-proxy:object-store glance:object-store


Starting with OpenStack Mitaka improved telemetry collection support can be achieved by adding a relation to rabbitmq-server:

juju add-relation swift-proxy rabbitmq-server

Doing the above in a busy Swift deployment can add a significant amount of load to the underlying message bus.

High availability

When more than one unit is deployed with the hacluster application the charm will bring up an HA active/active cluster.

There are two mutually exclusive high availability options: using virtual IP(s) or DNS. In both cases the hacluster subordinate charm is used to provide the Corosync and Pacemaker backend HA functionality.

See OpenStack high availability in the OpenStack Charms Deployment Guide for details.

Network spaces

This charm supports the use of Juju network spaces (Juju v.2.0). This feature optionally allows specific types of the application's network traffic to be bound to subnets that the underlying hardware is connected to.

Note: Spaces must be configured in the backing cloud prior to deployment.

API endpoints can be bound to distinct network spaces supporting the network separation of public, internal, and admin endpoints.

For example, providing that spaces 'public-space', 'internal-space', and 'admin-space' exist, the deploy command above could look like this:

juju deploy --config swift-proxy.yaml swift-proxy \
   --bind "public=public-space internal=internal-space admin=admin-space"

Alternatively, configuration can be provided as part of a bundle:

      charm: cs:swift-proxy
      num_units: 1
        public: public-space
        internal: internal-space
        admin: admin-space

Note: Existing cinder units configured with the os-admin-network, os-internal-network, or os-public-network options will continue to honour them. Furthermore, these options override any space bindings, if set.


This section lists Juju actions supported by the charm. Actions allow specific operations to be performed on a per-unit basis.

  • add-user
  • diskusage
  • dispersion-populate
  • dispersion-report
  • openstack-upgrade
  • pause
  • remove-devices
  • resume
  • set-weight

To display action descriptions run juju actions swift-proxy.

Policy Overrides

This feature allows for policy overrides using the policy.d directory. This is an advanced feature and the policies that the OpenStack service supports should be clearly and unambiguously understood before trying to override, or add to, the default policies that the service uses. The charm also has some policy defaults. They should also be understood before being overridden.

Caution: It is possible to break the system (for tenants and other services) if policies are incorrectly applied to the service.

Policy overrides are YAML files that contain rules that will add to, or override, existing policy rules in the service. The policy.d directory is a place to put the YAML override files. This charm owns the /etc/swift/policy.d directory, and as such, any manual changes to it will be overwritten on charm upgrades.

Overrides are provided to the charm using a Juju resource called policyd-override. The resource is a ZIP file. This file, say overrides.zip, is attached to the charm by:

juju attach-resource swift-proxy policyd-override=overrides.zip

The policy override is enabled in the charm using:

juju config swift-proxy use-policyd-override=true

When use-policyd-override is True the status line of the charm will be prefixed with PO: indicating that policies have been overridden. If the installation of the policy override YAML files failed for any reason then the status line will be prefixed with PO (broken):. The log file for the charm will indicate the reason. No policy override files are installed if the PO (broken): is shown. The status line indicates that the overrides are broken, not that the policy for the service has failed. The policy will be the defaults for the charm and service.

Policy overrides on one service may affect the functionality of another service. Therefore, it may be necessary to provide policy overrides for multiple service charms to achieve a consistent set of policies across the OpenStack system. The charms for the other services that may need overrides should be checked to ensure that they support overrides before proceeding.


Please report bugs on Launchpad.

For general charm questions refer to the OpenStack Charm Guide.