Note that the following holds true for all of the described upgrade scenarios:
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 scenaior, you upgrade one service at a time. You perform
rolling upgrades of your compute hosts, taking advantage of the fact
that nova-compute
from Juno can communicate with a Kilo control
plane.
Pros: This process minimizes the downtime to your existing compute workloads.
This is our recommended upgrade procedure for most environments.
Cons: This is a more complex procedure, and mistakes or undiscovered compatibility issues can unexpectedly turn it into Scenario 1.
Read about this scenario in Upgrade Scenario 2 (HA) if you are running an HA environment, or Upgrade Scenaior 2 (non-HA) if you are running in a non-HA environment.