Upgrade

An upgrade moves the platform to a newer release in place, with its data. This page covers both install paths.

Before you upgrade

Read the release notes for every release between yours and the target (Release notes).
Back up the database. To go back, you restore this backup and install the previous release. With the managed database, confirm the latest base backup completed and archiving is current (Backup and restore); with your own database, use your own tooling.
Mirror the new release first on an air-gapped install, and verify its signatures (Air-gapped installation).
Confirm you hold the master key. The upgrade reads it from the same Secret; under GitOps it must come from a Secret your tooling manages (Before you start).

How the schema moves

Each new pod applies pending migrations before it serves. During a rolling upgrade the old pods keep serving against the new schema, so every release’s migrations are backward compatible with the release before it. The control plane reports not ready until the schema matches its version.

Upgrade a Helm install

Use the same values files as the install:

helm upgrade olympus oci://<registry>/charts/olympus --version <new-version> \
  -n olympus -f olympus-values.yaml --wait --timeout 20m

On OpenShift, keep the install’s file order, the OpenShift values first and yours second:

helm pull oci://<registry>/charts/olympus --version <new-version> --untar -d ./chart-new
helm upgrade olympus ./chart-new/olympus -n olympus \
  -f ./chart-new/olympus/values-openshift.yaml \
  -f olympus-values.yaml --wait --timeout 20m

Reversed, the upgrade reverts to an Ingress and pinned user IDs.

--version moves the chart and the platform together. To move one image only, as when pinning a verified digest, set that component’s image.tag (a tag may carry a digest: <version>@sha256:<digest>).

Upgrade an operator install

Two things upgrade: the operator, through OLM, and the platform, through the operator.

The operator

Point the catalog at the new release’s catalog image:

oc -n openshift-marketplace patch catalogsource olympus-operators \
  --type=merge -p '{"spec":{"image":"<new-catalog-image>"}}'

On vanilla Kubernetes the CatalogSource is in the olm namespace and the operator in operators; replace the namespaces in these commands.

With installPlanApproval: Automatic, OLM installs the new operator once the catalog serves it. With Manual, OLM creates an InstallPlan and waits:

oc -n openshift-operators get installplan
# NAME            CSV                                APPROVAL   APPROVED
# install-abc12   olympus-operator.v<new-version>    Manual     false

oc -n openshift-operators patch installplan install-abc12 \
  --type=merge -p '{"spec":{"approved":true}}'

In the web console, the same is Review manual InstallPlan on the operator’s Subscription page. Wait for the new ClusterServiceVersion:

oc -n openshift-operators get csv -w
# olympus-operator.v<new-version>   Olympusx AI   <new-version>   Succeeded

The platform

With spec.version empty, the platform follows the operator: the version each operator ships with is the pairing it was tested with, and the new operator upgrades the platform on its next reconcile.

With spec.version pinned, change it:

oc -n olympus patch olympuses.olympus.olympusx.ai olympus \
  --type=merge -p '{"spec":{"version":"<new-version>"}}'

Watch the resource:

oc -n olympus get olympuses.olympus.olympusx.ai olympus -w

VERSION shows status.appliedVersion, what is actually running. READY returns to True when every component on the new version is available.

What an upgrade does not change

Settings applied with the realm. The first administrator, the mail relay, the realm name and the password policy reach the built-in identity service once, at the first install. Change them on a running platform in its administration console (Identity and sign-in).
Running model deployments. Each keeps the runtime image its plan pinned until it is deployed again.
The master key. It is never rotated by an upgrade.

After the upgrade

Run Verify the installation. If the upgrade fails partway, the failing pod’s log names the cause; see Troubleshooting. To go back, restore the backup you took and install the previous release against it.