Update STRATUM

STRATUM upgrades replace the application container image while persistent host state remains outside that image. Before loading a new release, preserve the currently running image with a permanent version tag. That gives the controller a known-good rollback point before the latest tag moves to the new release.

Retagging an image does not disturb the running STRATUM container. A running container remains attached to the image ID it started from even if stratum:latest is later moved to a different image. The new code is not used until the STRATUM container is stopped, removed, and started again.

Identify the image that is running today and tag it with the release number you want to preserve. The image ID below is an example; use the ID from your host.

After tagging, verify that both latest and the permanent release tag point to the same current image before loading the upgrade archive.

Load the supplied STRATUM container archive. When the archive was exported as stratum:latest, Docker moves the latest tag to the newly loaded image. The old release remains available under the permanent tag created in the previous step.

Give the new image its own permanent release tag as well. Keeping both release tags makes the active version and rollback target explicit.

Loading and retagging the image does not change the container that is already running. Use stratum-host to stop and replace the configured STRATUM container so the new image is selected on the next start.

The remove operation is part of the intended STRATUM upgrade path. Before the old container is destroyed, stratum-host runs the runtime upgrade-state preservation path, including the controller database migration case. Persistent host data and certificates remain outside the replaceable application container.

Replace the example image ID and release tags with the values for the release being upgraded.

Do not delete the previous version tag as soon as the upgrade starts. Keep the known-good image available until the new controller has started, the interface is reachable, and normal datacenter operations have been validated.

If a rollback is required, configure STRATUM to use the preserved earlier image tag and replace the container through the same stratum-host stop/remove/start path. The persistent controller state remains outside the application image; the versioned image tag controls which STRATUM application release starts against that state.

The new STRATUM image is loaded and permanently tagged, the previous release remains available for rollback, and stratum-host has recreated the application container against the persistent STRATUM host state.