Note that the following holds true for all of the following scenarios:
- All scenarios involve some service interruptions.
- Running instances will not be affected by the upgrade process unless you (a) reboot a compute node or (b) explicitly shut down an instance.
In this scenario, you will take down all of your OpenStack services at the same time, and will not bring them back up until the upgrade process is complete.
Pros: This process is very simple. Because everything is down there is no orchestration involved.
Cons: All of your services are unavailable all at once. In a large environment, this can result in a potentially extensive downtime as you wait for database schema upgrades to complete.
Read about this scenario in Upgrade Scenario 1.
In this scenario, you upgrade one service at a time.
Pros: Rather than a single large service outage you are able to stage outages to specific services. You schedule potentially longer upgrades -- such as the compute service upgrade in a large environment -- separately from upgrades that take less time.
Cons: You will still have an interruption to your Nova APIs and compute nodes.
Read about this scenario in Upgrade Scenario 2.
For most services this scenario is identical to scenario 2, with the exception of the Nova controller and compute services. Rather than upgrading your existing Nova environment as part of this process, you deploy new nodes running the Juno Nova services. You wait for existing workloads on your Icehouse compute nodes to complete (or migrate them by hand), and when an Icehouse compute node is no longer hosting any instances you upgrade the compute service on that node.
Pros: This minimizes interruptions to your compute service. Existing workloads can run indefinitely, and you do not need to wait for a database migration.
Cons: This requires additional hardware resources to bring up the Icehouse Nova nodes.
Read about this scenario in Upgrade Scenario 3.
For most services this scenario is identical to scenario 2, with the
exception of the Nova controller and compute services. In this
scenario, you will take advantage of the fact that Icehouse nova-compute can communicate with Juno control services in order to perform a rolling upgrade of compute services across your environment.
Like scenario 3, this process minimizes the downtime to your existing compute workloads, but does not require a parallel environment to support the process.
This is our recommended upgrade procedure for most environments.
Read about this scenario in Upgrade Scenario 4.