This document outlines steps and notes for operators for reference when upgrading their Load Balancing service from previous versions of OpenStack.
Before jumping right in to the upgrade process, there are a few considerations operators should observe:
In a cold upgrade (also known as offline upgrade and non-rolling upgrade), the Load Balancing service is not available because all the control plane services have to be taken down. No data plane disruption should result during the course of upgrading. In the case of the Load Balancing service, it means no downtime nor reconfiguration of service-managed resources (e.g. load balancers, listeners, pools and members).
octavia-db-manage upgrade head
from any Octavia node to upgrade the
database and run any corresponding database migrations.Amphorae upgrade may be required in the advent of API incompatibility between the running amphora agent (old version) and Octavia services (new version). Octavia will automatically recover by failing over amphorae and thus new amphora instances will be running on latest amphora agent code. The drawback in that case is data plane downtime during failover. API breakage is a very rare case, and would be highlighted in the release notes if this scenario occurs.
Grenade is an OpenStack test harness project that validates upgrade scenarios between releases. It uses DevStack to initially perform a base OpenStack install and then upgrade to a target version.
Octavia has a Grenade plugin and a CI gate job that validates cold upgrades of an OpenStack deployment with Octavia enabled. The plugin creates load balancing resources and verifies that resources are still working during and after upgrade.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.