Before running a rolling upgrade, some steps must be completed first.
Verify that HTTPS certificates are valid
The HTTPS certificates on the VMs must be valid for more than 30 days, and must remain valid during the upgrade for the whole deployment. For example, your upgrade will fail if your certificate is valid for 32 days and it takes more than 1 day to upgrade all of the VMs for all node types.
Using your own certificates
If using your own generated certificates, check its expiry date using:
openssl x509 -in <certificate file> -enddate -nooutIf the certificates are expiring, you must first upload the new certificates using rvtconfig upload-config before upgrading.
Using VM generated certificates
If you did not provide certificates to the VMs, the VM will generate its own certificates which are valid for 5 years. So if the current VMs have been deployed less than 5 years ago then there is nothing further to do. If it has been over 5 years, then please contact your Metaswitch Customer Care representative.
Verify all VMs are healthy
All the VMs in the deployment need to be healthy. To check this, run the common health checks for the VMs by following: Verify the state of the nodes and processes.
Upload the uplevel CSARs to the SIMPL VM
If not already done, transfer the uplevel CSARs onto the SIMPL VM.
For each CSAR, run csar unpack <path to CSAR>, where <path to CSAR> is the full path to the transferred uplevel CSAR.
This will unpack the uplevel CSARs to ~/.local/share/csar/.
Upload the uplevel SDF to SIMPL VM
If the CSAR uplevel SDF was not created on the SIMPL VM, transfer the previously written CSAR uplevel SDF onto the SIMPL VM.
|
Ensure that each version in the vnfcs section of the uplevel SDF matches each node type’s CSAR version.
|
Upload uplevel RVT configuration
Upload the uplevel configuration for all of the node types to the CDS. This is required for the rolling upgrade to complete.
|
|
As configuration is stored against a specific version, you need to re-upload, the uplevel configuration even if it is identical to the downlevel configuration. |
When performing a rolling upgrade some elements of the uplevel configuration must remain identical to those in the downlevel configuration. These elements (and the remedy if that configuration change was made and the cluster upgrade process started) are described in the following table:
Node Type |
Disallowed Configuration Change |
Remedy |
All |
The |
Rollback the affected VM(s) to restore the original configuration, then correct the uplevel configuration and re-run the upgrade. |
All |
The ordering of the VM instances in the SDF may not be altered. |
Rollback the affected VM(s) to restore the original configuration, then correct the uplevel configuration and re-run the upgrade. |
See Example configuration YAML files for example configuration files.
