← Back to team overview

openstack team mailing list archive

[swift] important upgrade note for swift deployers


Swift 1.7

The next release of Swift will be version 1.7. This will be our
release for OpenStack Folsom, and is scheduled land mid-September.
There is an important change for deployers in this release. This
email has the details so you can begin planning your upgrade path.

What's the change

The version bump is based in part on a recent patch that changed the
on-disk format of the ring files
(https://github.com/openstack/swift/commit/f8ce43a21891ae2cc00d0770895b556eea9c7845 ).
This was a necessary change that addresses a major performance issue
introduced by a change in Python between Py2.6 and Py2.7. See
https://bugs.launchpad.net/swift/+bug/1031954 for more detail.

This patch essentially changes a default in a backwards incompatible
way. Swift 1.7 can read the old format but only write the new format.
Therefore deployers can easily upgrade but not easily downgrade or
roll back this part of the system.

This information is included in the official docs at

Safe Upgrade Path

This is how deployers can safely upgrade their existing swift cluster:

1) Upgrade the proxy, account, container, and object nodes as normal.
   Cluster operations will continue to work and you can still upgrade
   with no downtime, as always.

2) Once your entire cluster is upgraded, only then upgrade the version
   of swift on the box that builds your ring files (ie where you run
   swift-ring-builder). Upgrading this piece will change the on-disk
   format of your generated ring files. Deploy the new ring files to the
   swift cluster.


 - Swift 1.7 can read both old and new format ring files.

 - If you upgrade the swift-ring-builder to the new format and
   generate new ring files with it, you cannot downgrade your cluster
   and use the new rings.

Oh No! I really, really have to downgrade my cluster

1) Downgrade your box where you run swift-ring-builder

2) Rebalance and write out rings (to put them in the old format) and
   deploy them to your cluster

3) Downgrade the rest of the swift cluster