​

Upgrades

# The version you are moving TO — the newer tarball we sent you.
export SWARMD_CHART=~/Downloads/swarmd-<new-version>.tgz

helm upgrade swarmd $SWARMD_CHART -n swarmd \
  -f my-values.yaml \
  --wait --timeout 15m

​

Upgrade checklist

1. Read the release notes for every version between yours and the target, and prepare your values file from the new version’s preset (Before you run it, step 1).
2. Check the chart file is the version you expect: helm show chart $SWARMD_CHART.
3. Back up both databases and the swarmd-generated-credentials Secret, and note the current Helm revision — it is the one you would roll back to.
4. Preview the upgrade with --dry-run=server (or helm diff).
5. Upgrade in a quiet window, with --wait --timeout 15m.
6. Verify straight away: pods Running with zero restarts, helm test passes, and one real message reaches an agent (Verifying afterwards).
7. Do any after-upgrade steps the release notes list.

​

Getting the new version

• Keep old tarballs. helm rollback restores the previous revision from what Helm already has, so it works without the file. Reinstalling an older release from scratch does not — that needs the tarball again, and asking us for it is a slower path than keeping a copy.
• Name your releases after the file. helm -n swarmd list shows the chart version, so a cluster can always tell you what it is running; keeping the tarballs in one directory makes it just as easy in the other direction.

helm show chart $SWARMD_CHART

​

What survives an upgrade

​

The one that bricks installs

Refusing to upgrade: could not read the existing Secret
"swarmd-generated-credentials" in namespace "swarmd".

helm upgrade swarmd $SWARMD_CHART -n swarmd \
  -f my-values.yaml --dry-run=server

global:
  generatedSecrets:
    enabled: false
    name: swarmd-generated-credentials

kubectl -n swarmd get secret swarmd-generated-credentials \
  -o jsonpath='{.data.encryption-key}' | base64 -d

​

Before you run it

diff my-values.yaml values-prismforce-local.yaml

PGUSER=$(kubectl -n swarmd get secret swarmd-generated-credentials -o jsonpath='{.data.postgres-username}' | base64 -d)
PGPASS=$(kubectl -n swarmd get secret swarmd-generated-credentials -o jsonpath='{.data.postgres-password}' | base64 -d)
for db in swarmd keycloak; do
  kubectl -n swarmd exec deploy/swarmd-postgres -- \
    env PGPASSWORD="$PGPASS" pg_dump -U "$PGUSER" -Fc "$db" > "$db-before-upgrade.dump"
done

helm -n swarmd history swarmd --max 1

kubectl -n swarmd get secret swarmd-generated-credentials -o yaml > swarmd-credentials-backup.yaml

kubectl -n swarmd get secret swarmd-generated-credentials

helm upgrade swarmd $SWARMD_CHART -n swarmd \
  -f my-values.yaml --dry-run=server

​

What happens during the rollout

services:
  gateway:
    replicaCount: 2
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

1. Migration Jobs run to completion (pre-upgrade hooks, Flyway, forwards only). A service with worker.enabled: false — every service in values-prismforce-local.yaml — has no Job and migrates as its pod starts instead.
2. Pods replaced one service at a time, each held at Init:0/1 until Keycloak’s realm answers.
3. The realm bootstrap Job for the new revision runs and exits early, because the realm already exists.

​

Rolling back

helm -n swarmd history swarmd
# REVISION  CHART         APP VERSION  DESCRIPTION
# 1         swarmd-1.4.0  1.4.0        Install complete
# 2         swarmd-1.5.0  1.5.0        Upgrade complete

helm rollback swarmd 1 -n swarmd --wait --timeout 15m

​

Rolling back with a restore

NS=swarmd
PGUSER=$(kubectl -n $NS get secret swarmd-generated-credentials -o jsonpath='{.data.postgres-username}' | base64 -d)
PGPASS=$(kubectl -n $NS get secret swarmd-generated-credentials -o jsonpath='{.data.postgres-password}' | base64 -d)
pg() { kubectl -n $NS exec -i deploy/swarmd-postgres -- env PGPASSWORD="$PGPASS" "$@"; }

# 1. Remember each workload's replica count, then stop everything but Postgres.
REPLICAS=$(kubectl -n $NS get deploy -l app.kubernetes.io/instance=swarmd \
  -o jsonpath='{range .items[*]}{.metadata.name}={.spec.replicas}{" "}{end}')
kubectl -n $NS scale deploy -l app.kubernetes.io/instance=swarmd --replicas=0
kubectl -n $NS scale deploy/swarmd-postgres --replicas=1
kubectl -n $NS rollout status deploy/swarmd-postgres --timeout=5m

# 2. Recreate each database empty and restore into it.
for db in swarmd keycloak; do
  pg dropdb -U "$PGUSER" --if-exists --force "$db"
  pg createdb -U "$PGUSER" -O "$PGUSER" "$db"
  pg pg_restore -U "$PGUSER" -d "$db" --exit-on-error --single-transaction < "$db-before-upgrade.dump"
done

# 3. Start everything again.
for r in $REPLICAS; do kubectl -n $NS scale "deploy/${r%%=*}" --replicas="${r##*=}"; done
kubectl -n $NS rollout status deploy -l app.kubernetes.io/instance=swarmd --timeout=15m

• swarmd-generated-credentials. The rollback puts the Secret back as the older release wrote it, so keys the newer version added are removed. That is safe: encryption-keys is derived from encryption-key, and the per-service Keycloak client secrets are regenerated and re-applied to Keycloak by each service at start, so upgrading again rebuilds both. The keys the older version uses are never changed.
• ClickHouse. Its volume is kept when a rollback removes ClickHouse, so its data is still there when you upgrade again.

​

Skipping versions

​

Verifying afterwards

# Every pod Running, zero restarts
kubectl -n swarmd get pods

# Migration Jobs completed, not failed
kubectl -n swarmd get jobs

# The release is at the version you asked for
helm -n swarmd list

helm test swarmd -n swarmd --logs

​

Next