Actualización de la nube (strongctl upgrade)

strongctl upgrade aplica actualizaciones de corrección a una nube StrongLinux: versiones nuevas de los paquetes dentro de la misma serie de OpenStack (2026.1). La nube sigue en marcha durante la actualización: las VM continúan ejecutándose y las APIs siguen respondiendo.

El cambio de serie (por ejemplo 2026.1 → 2027.1, la ruta SLURP) no está cubierto: el comando se niega cuando cambia la versión mayor de algún servicio OpenStack.

Canales

Los paquetes vienen del repositorio apt de StrongLinux:

Canal	Contenido
`stronglinux-1.0`	versiones del lanzamiento
`stronglinux-1.0-updates`	correcciones aprobadas (pasaron la prueba M3 y Tempest en el pipeline)
`stronglinux-1.0-security`	correcciones de seguridad
`stronglinux-1.0-proposed`	candidatos, solo para pruebas

Los canales que usa la nube están en stronglinux_apt_suites en /etc/strongctl/globals.yml. Para probar candidatos, agregue stronglinux-1.0-proposed a la lista.

Paso a paso

Actualice primero el propio strongctl, porque los roles y plantillas nuevos vienen con él (strongctl upgrade se niega a ejecutarse si hay una versión nueva de strongctl):
```
apt update && apt install --only-upgrade strongctl
```
Vea qué cambia en cada nodo (no modifica nada):
```
strongctl upgrade --listar
```
Actualice:
```
strongctl upgrade
```

Qué hace el comando

Comprobación previa: ejecuta verify; la nube debe estar sana. Use --sem-verificar solo si sabe lo que está haciendo.
Fuentes apt en todos los nodos (rol common). Luego obtiene, por nodo, los paquetes stronglinux-* con versión nueva y rechaza un cambio de serie.
Controllers, de uno en uno. Para cada uno:
- actualiza los paquetes, conservando la configuración local (--force-confold); el postinst de cada servicio reinicia solo las units que ya estaban en marcha;
- espera a que las units habilitadas vuelvan y a que Keystone responda;
- con HA, espera a que Galera esté Synced.
Con HA, HAProxy saca del balanceo el controller que se está reiniciando.
Resto de nodos (cómputo, red y almacenamiento), por lotes. El tamaño del lote se define con --serial; por defecto es el 25% de los nodos.
Deploy: escribe la configuración nueva, ejecuta las migraciones de esquema (db sync, una vez por nube) y reinicia lo que cambió.
Migraciones de datos en línea de nova y cinder (online_data_migrations, hasta terminar).
Verify final.

Ejecutar strongctl upgrade otra vez sin paquetes nuevos no cambia nada (changed=0).

Paquetes de Ubuntu

strongctl upgrade se ocupa de los paquetes de StrongLinux. Los paquetes de Ubuntu (OVS/OVN, MariaDB, RabbitMQ, libvirt, kernel) siguen la política de actualización del sistema. Para actualizaciones que reinician OVS, libvirt o el kernel, actualice un nodo a la vez y, en los nodos de cómputo, migre antes las VM.

Validación

La prueba tests/lxd/run-smoke.sh strongctl-upgrade hace un ciclo completo:

Despliega una nube all-in-one desde el canal estable.
Crea una VM con IP flotante y un volumen.
Agrega el canal proposed y ejecuta strongctl upgrade, midiendo todo el tiempo:
- ping a la IP flotante;
- emisión de un token cada 5 s.
Comprueba después de la actualización:
- las versiones nuevas instaladas;
- la VM en marcha;
- una VM nueva;
- una segunda actualización sin cambios;
- Tempest smoke.