Upgrade to version 1.15

Check the following before upgrading.

• webmon-cli. Update the tool to 0.5.8 or newer. The web monitoring API now takes the whole site specification: a field missing from a PUT request is reset to its default. Other API clients that send only part of the fields have to send the whole site specification.
• Severity of web monitoring alerts. Checks that get no checkLabels from the site, the probe or the check itself now alert with critical severity. Set the labels explicitly where another severity is wanted.
• Web monitoring log format. The text of the log records about failed checks has changed. Log queries and alerts matching the old messages have to be rewritten.
• Storage cache size. The None value of storage.metrics.cacheSize, storage.logs.cacheSize and storage.traces.cacheSize is no longer accepted. If it is set, replace it with Small.
• Domain settings. general.baseDomain, general.clusterBaseDomain, monitoring.customDomain.baseDomain and monitoring.customDomain.collectorDomain must be valid fully qualified domain names: values with underscores, empty labels or a trailing dot fail configuration validation.

Upgrade to version 1.10

Migration from operator-postgres to managed-postgres (Deckhouse Observability Platform version 1.10)

Starting from Deckhouse Observability Platform version 1.10, the managed-postgres module is used instead of operator-postgres. Support for operator-postgres will be removed in Deckhouse Observability Platform version 1.12.

Important: If you see the NeedMigrationPostgres alert, follow this guide to migrate your PostgreSQL database.

Prerequisites

• Ensure you have access to the Kubernetes cluster with kubectl

Migration Steps

1. Enable the managed-postgres module:

   d8 system module enable managed-postgres

2. Wait for the new PostgreSQL database to be provisioned. This may take several minutes as it requires two module reconciliation cycles:

   echo "Waiting for managed-postgres-credentials secret..."
   until kubectl -n d8-observability-platform get secret managed-postgres-credentials &>/dev/null; do
     sleep 10
   done
   echo "Done"

3. Save the current replica counts and stop the backend and alertgate components:

   export BACKEND_REPLICAS=$(kubectl -n d8-observability-platform get deploy backend -o jsonpath='{.spec.replicas}')
   export ALERTGATE_REPLICAS=$(kubectl -n d8-observability-platform get deploy alertgate-receiver -o jsonpath='{.spec.replicas}')
   kubectl -n d8-observability-platform scale deploy backend alertgate-receiver alertgate-sender alertgate-api --replicas=0

4. Export the password for the new PostgreSQL instance:

   export PGPASSWORD=$(kubectl -n d8-observability-platform get secret managed-postgres-credentials \
     -o jsonpath='{.data.password}' | base64 -d)

5. Dump the old database to a local file:

   kubectl -n d8-observability-platform exec -i \
     $(kubectl -n d8-observability-platform get po -l spilo-role=master -o name) \
     -- /usr/lib/postgresql/14/bin/pg_dump -U dop --no-privileges --no-owner --inserts dop > /tmp/dop-dump.sql

6. Import the dump into the new database:

   { echo "SET session_replication_role = 'replica';"; cat /tmp/dop-dump.sql; } | \
     kubectl -n d8-observability-platform exec -i \
     $(kubectl -n d8-observability-platform get po -l cnpg.internal.managed.deckhouse.io/instanceRole=primary -o name) \
     -- sh -c "PGPASSWORD='$PGPASSWORD' psql -q -h localhost -U dop dop"

   Note: Errors about existing schemas (metric_helpers, user_management), unavailable extensions (pg_stat_statements, pg_stat_kcache, set_user), or already existing functions are safe to ignore — these are system objects from operator-postgres that are not needed in managed-postgres.

7. Mark the migration as completed:

   kubectl -n d8-observability-platform create cm postgres-migrated-completed

8. Restore the backend and alertgate components:

   kubectl -n d8-observability-platform scale deploy backend --replicas=$BACKEND_REPLICAS
   kubectl -n d8-observability-platform scale deploy alertgate-receiver alertgate-sender alertgate-api --replicas=$ALERTGATE_REPLICAS

9. Verify that the Deckhouse Observability Platform web interface is accessible and opens without errors. Workspaces and projects are displayed. Dashboards open without errors, and metrics data is correct.

Rollback (if needed)

If you encounter problems after migration, you can switch back to operator-postgres:

1. Save the current replica counts and stop the backend and alertgate components:

   export BACKEND_REPLICAS=$(kubectl -n d8-observability-platform get deploy backend -o jsonpath='{.spec.replicas}')
   export ALERTGATE_REPLICAS=$(kubectl -n d8-observability-platform get deploy alertgate-receiver -o jsonpath='{.spec.replicas}')
   kubectl -n d8-observability-platform scale deploy backend alertgate-receiver alertgate-sender alertgate-api --replicas=0

2. Remove the migration marker:

   kubectl -n d8-observability-platform delete cm postgres-migrated-completed

3. Restore the backend and alertgate components:

   kubectl -n d8-observability-platform scale deploy backend --replicas=$BACKEND_REPLICAS
   kubectl -n d8-observability-platform scale deploy alertgate-receiver alertgate-sender alertgate-api --replicas=$ALERTGATE_REPLICAS

Cleanup (after successful migration)

After verifying that the migration was successful, disable the operator-postgres module. The operator will stop running, but CRDs and the old PostgreSQL CR will remain in the cluster — this is harmless. Full cleanup of old resources will be performed automatically in version 1.12.

d8 system module disable operator-postgres