Key Manager Service Upgrade Guide

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.

Creative Commons Attribution 3.0 License

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