Introduction

StarlingX software management enables you to upversion your StarlingX software to a new Patch Release or a new Major Release.

Major Releases (versioned as ‘nn.nn’, for example, starlingx-13.0)

  • deliver new and enhanced feature content

  • are packaged and delivered as install ISOs containing all software packages

  • delivers fixes for known bugs and CVE vulnerabilities

  • are packaged and delivered as patch archive files

    • containing only new and changed software packages

    • with meta data to indicate dependencies on previously released Patch Releases or the associated Major Release

Both Major Releases and Patch Releases are cryptographically signed to ensure integrity and authenticity, and the StarlingX REST APIs, CLIs, and GUI validate the signature of software releases before loading them into the system.

Both Major Releases and Patch Releases can be deployed using either:

or

Both manual and orchestrated procedures use a ‘rolling deployment’ procedure for deploying the software of the new release. StarlingX hosts are updated/upgraded one (or more) at a time such that StarlingX can continue to provide hosting services to its hosted applications on other StarlingX hosts.

Specifically:

  • Controllers are updated/upgraded one at a time,

  • then Storage hosts are updated/upgraded one (or more) at a time, respecting Storage host redundancy,

  • then Worker hosts are updated/upgraded one (or more) at a time.

For a Major Release deployment, the upgrading of a new Major Release will result in a reboot of each host, as the host is upgraded with the new Major Release, in order for the host to boot into the new software’s root filesystem.

For a Patch Release deployment, depending on the type of software changes in the Patch Release, one of two deployment modes will be used:

In-Service

in this mode, the upversioning to a new Patch Release will only result in the install of new software and the restart of the required services, as each host is upversioned with the new Patch Release.

Reboot-Required (RR)

in this mode, the upversioning to a new Patch Release will result in a reboot of each host, as the host is upversioned to the new Patch Release.

For either a Patch Release or a Major Release, an Abort and Rollback of the active software deployment is supported. The deployment of a Release can be aborted and rolled back at any step of the deployment process, as long as the active deployment has not been both completed and deleted.

The default rollback procedure for both Patch Release and Major Release rollbacks for all deployment configurations, involves reverting changes to individual files across the main logical volumes during the deployment. For Major Release rollbacks, on AIO-SX configurations only, an LVM snapshot option can be used to take a snapshot of the main logical volumes at the start of deployment, such that in case of a rollback, the LVM snapshots can be restored in order to speed up the overall rollback procedure.

Note

Snapshots are created with a size that determines its capacity to track the changes in the corresponding logical volume. When a snapshot reaches its maximum capacity, the snapshot becomes invalid and cannot be restored. In this case, the system will automatically fall back to the standard rollback procedure.

For a Patch Release only, a removal or un-deployment of a release is supported. One or more Patch Releases can be removed/un-deployed by deploying a previous Patch Release.

Componentization and Metapackages

Releases are internally packaged and partitioned into components called metapackages. Each metapackage groups a set of software packages related to a specific platform competence. For example:

  • base — core platform packages

  • infra — infrastructure-related packages

  • distcloud — distributed cloud packages

  • k8s-common, k8s-v<version> — Kubernetes packages

  • swmgmt — software management packages

Some product-level releases, for example StarlingX-nn.nn, support independent deployment of these metapackages. This allows you to deploy a specific metapackage, such as base-nn.nn, without deploying the other metapackages included in the corresponding StarlingX-nn.nn release.

For more information, see Manual Metapackage Host Software Deployment.

Kubernetes Upgrades

In addition to StarlingX host software updates and upgrades, StarlingX software management enables you to upgrade the version of Kubernetes running on your StarlingX. As each StarlingX release supports two or more consecutive Kubernetes versions, a Kubernetes upgrade allows you to move the Kubernetes control plane and worker (kubelet) components from one supported version to another, independently of a host software Major or Patch Release.

Kubernetes upgrades can be performed using either:

or

Like host software deployments, Kubernetes upgrades follow a rolling procedure so that StarlingX can continue to provide hosting services to its hosted applications while the upgrade is in progress. Multi-version Kubernetes upgrades are also supported, allowing you to move across several Kubernetes minor versions in a single upgrade cycle rather than upgrading through each intermediate version one at a time.

Sequencing of Host Software and Kubernetes Upgrades

In the legacy (default) upgrade flow, host software deployment and Kubernetes upgrades are performed sequentially, as two separate operations. In this model, you first complete the host software deployment (the Major Release or Patch Release deployment across all StarlingX hosts), and only after that deployment has been completed do you perform the Kubernetes version upgrade.

This sequencing applies to all deployment configurations, and each operation independently follows its own rolling, host-by-host procedure. As a result, the host software deployment and the subsequent Kubernetes upgrade each contribute their own duration and, where applicable, their own service impact.

Combined Host Software and Kubernetes Upgrades (AIO-SX Only)

For AIO-SX deployments only, the host software upgrade and the Kubernetes upgrade can be combined into a single operation, rather than being run as two separate, sequential procedures.

Combining the host software upgrade and the Kubernetes upgrade in this way provides:

  • a reduced overall upgrade duration, since the two operations are carried out together instead of one after the other, and

  • a reduced service outage, as the combined upgrade avoids the additional disruption that would otherwise be incurred by running the Kubernetes upgrade as a separate operation after the host software deployment.

Note

Combining host software upgrades with Kubernetes upgrades is supported on AIO-SX configurations only. On all other deployment configurations, host software deployments and Kubernetes upgrades must be performed sequentially as two separate operations.