Updating the cloud (strongctl upgrade)

strongctl upgrade applies bug-fix updates to a StrongLinux cloud: new package versions within the same OpenStack series (2026.1). The cloud stays up during the update: VMs keep running and the APIs keep answering.

Changing series (for example 2026.1 → 2027.1, the SLURP path) is not covered: the command refuses when the major version of any OpenStack service changes.

Channels

Packages come from the StrongLinux apt repository:

Channel	Contents
`stronglinux-1.0`	release versions
`stronglinux-1.0-updates`	approved fixes (passed the M3 test and Tempest in the pipeline)
`stronglinux-1.0-security`	security fixes
`stronglinux-1.0-proposed`	candidates, for testing only

The channels a cloud uses are listed in stronglinux_apt_suites in /etc/strongctl/globals.yml. To test candidates, add stronglinux-1.0-proposed to the list.

Step by step

Update strongctl itself first, because new roles and templates ship with it (strongctl upgrade refuses to run if a newer strongctl is available):
```
apt update && apt install --only-upgrade strongctl
```

See what changes on each node (changes nothing):
```
strongctl upgrade --listar
```

Update:
```
strongctl upgrade
```

What the command does

Pre-check: runs verify; the cloud must be healthy. Use --sem-verificar only if you know what you are doing.
apt sources on every node (common role). Then lists, per node, the stronglinux-* packages with a new version, and refuses a series change.
Controllers, one at a time. For each one:

upgrades the packages, keeping local configuration (--force-confold); each service's postinst restarts only the units that were already running;
waits for the enabled units to come back and for Keystone to answer;
with HA, waits for Galera to be Synced. With HA, HAProxy takes the restarting controller out of the pool.

Other nodes (compute, network and storage), in batches. The batch size is set with --serial; the default is 25% of the nodes.
Deploy: writes the new configuration, runs the schema migrations (db sync, once per cloud) and restarts what changed.
Online data migrations for nova and cinder (online_data_migrations, until done).
Final verify.

Running strongctl upgrade again with no new packages changes nothing (changed=0).

Ubuntu packages

strongctl upgrade takes care of the StrongLinux packages. Ubuntu packages (OVS/OVN, MariaDB, RabbitMQ, libvirt, kernel) follow the system update policy. For updates that restart OVS, libvirt or the kernel, update one node at a time and, on compute nodes, migrate the VMs first.

Validation

The tests/lxd/run-smoke.sh strongctl-upgrade test runs a full cycle:

Deploys an all-in-one cloud from the stable channel.
Creates a VM with a floating IP and a volume.
Adds the proposed channel and runs strongctl upgrade, measuring throughout:

ping to the floating IP;
token issuance every 5 s.

Checks after the upgrade:

the new versions are installed;
the VM is up;
a new VM boots;
a second upgrade changes nothing;
Tempest smoke passes.