Upgrade Management Overview¶
You can upgrade StarlingX’s Distributed Cloud’s System Controller, and subclouds with a new release of StarlingX software.
About this task
Backup all yaml files that are updated using the Redfish Platform Management service. For more information, see Installing a Subcloud Using Redfish Platform Management Service.
You can use the CLI to manage upgrades. The workflow for upgrades is as follows:
To upgrade the Distributed Cloud system, you must first upgrade the System Controller. See Upgrading the System Controller Using the CLI.
Use Distributed Cloud Upgrade Orchestration to upgrade the subclouds. See Distributed Upgrade Orchestration Process Using the CLI.
To handle errors during an orchestrated upgrade, see Error Handling During An Orchestrated Upgrade.
For AIO-SX subclouds, end user container images in registry.local will be backed up during the upgrade process. This only includes images other than StarlingX system and application images. These images are limited to 5 GBytes in total size. If the system contains more than 5 GBytes of these images, the upgrade start will fail.
The following prerequisites apply to a Distributed Cloud upgrade management service.
Configuration Verification: Ensure that the following configurations are verified before you proceed with the upgrade on the Distributed Cloud and subclouds:
Run the system application-list command to ensure that all applications are running.
Run the system host-list command to list the configured hosts.
Run the dcmanager subcloud list command to list the subclouds.
Run the kubectl get pods --all-namespaces command to test that the authentication token validates correctly.
Run the fm alarm-list command to check the system health to ensure that there are no unexpected or management-affecting alarms.
Run the kubectl get host -n deployment command to ensure all nodes in the cluster have reconciled and is set to ‘true’.
Ensure controller-0 is the active controller.
The subclouds must all be AIO-SX, and must use the Redfish platform management service.
Remove Non GA Applications:
Use the system application-remove and system application-delete commands to remove the application on the subclouds:
Remove any non-GA and stx-openstack applications, from the Distributed Cloud system, if they exist.