A typical MCP cluster includes multiple components, such as DriveTrain, StackLight, OpenStack, OpenContrail, and Ceph. Most of MCP components have their own versioning schema. For the majority of the components, MCP supports multiple versions at once.
The upgrade of an MCP deployment to a new version is a multi-step process that needs to take into account the cross-dependencies between the components of the platform, and compatibility matrix of supported versions of the components.
The MCP components that do not have their own versioning schema within MCP and are versioned by the MCP release include:
The DriveTrain components: Aptly, Gerrit, Jenkins, Reclass, Salt formulas and their subcomponents
StackLight LMA
Caution
Before proceeding with the upgrade procedure, verify that you have updated DriveTrain including Aptly, Gerrit, Jenkins, Reclass, Salt formulas, and their subcomponents to the current MCP release version. Otherwise, the current MCP product documentation is not applicable to your MCP deployment.
For the MCP components with support for multiple versions, such as OpenStack or OpenContrail, you usually can select between two operations:
New minor versions of the components artifacts are installed. Services are restarted as necessary. This kind of update allows you to obtain the latest bug and security fixes for the components, but it typically does not change the components capabilities.
New major versions of the components artifacts are installed. Additional orchestration tasks are executed to change the components configuration, if necessary. This kind of update typically changes and improves the components capabilities.
The following table outlines a general upgrade and update procedure workflow of an MCP cluster. For the detailed upgrade and update workflow of MCP components, refer to the corresponding sections below.
# |
Stage |
Description |
---|---|---|
1 |
Perform the basic LCM update or upgrade:
|
|
2 |
Upgrade or update OpenContrail (if applicable) |
|
3 |
For OpenStack:
Caution We recommend that you do not upgrade or update OpenStack and RabbitMQ simultaneously. Upgrade or update the RabbitMQ component only once OpenStack is running on the new version. |
|
4 |
|
|
5 |
Caution We recommend that you do not upgrade or update OpenStack and RabbitMQ simultaneously. Upgrade or update the RabbitMQ component only once OpenStack is running on the new version. |
|
For Kubernetes:
|
||
6 |
|
|
7 |
For upgrade:
For update:
After the restart of every service, wait for the system to become healthy. |
|
8 |
Install security updates on all nodes. To reduce the size of new packages to be installed on a cluster during update or upgrade, this is the final step of the procedure. However, you can perform it at any stage to fetch only security patches. |
|
9 |
Apply issues resolutions requiring manual application described in the Addressed issues sections of all Maintenance updates. |
Apply fixes that require manual application for all maintenance updates one by one. |