# Key Manager Service Upgrade Guide

This document outlines several steps and notes for operators to reference when upgrading their barbican from previous versions of OpenStack.

## Plan to Upgrade

- The release notes should be read carefully before upgrading the barbican services. Starting with the Mitaka release, specific upgrade steps and considerations are well-documented in the release notes.

- Upgrades are only supported between sequential releases.

- When upgrading barbican, the following steps should be followed:

  1. Destroy all barbican services

  2. Upgrade source code to the next release

  3. Upgrade barbican database to the next release

     >     barbican-db-manage upgrade

  4. Start barbican services

## Upgrade from Newton to Ocata

The barbican-api-paste.ini configuration file for the paste pipeline was updated to add the http_proxy_to_wsgi middleware. It can be used to help barbican respond with the correct URL refs when it’s put behind a TLS proxy (such as HAProxy). This middleware is disabled by default, but can be enabled via a configuration option in the oslo_middleware group.

See Ocata release notes.

## Upgrade from Mitaka to Newton

There are no extra instructions that should be noted for this upgrade.

See Newton release notes.

## Upgrade from Liberty to Mitaka

The Metadata API requires an update to the Database Schema. Existing deployments that are being upgraded to Mitaka should use the ‘barbican-manage’ utility to update the schema.

If you are upgrading from previous version of barbican that uses the PKCS#11 Cryptographic Plugin driver, you will need to run the migration script.

>     python barbican/cmd/pkcs11_migrate_kek_signatures.py

See Mitaka release notes.

this page last updated: 2026-08-18 22:10:53

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug