Skip to main content

Upgrade or rollback an application

Smart upgrade falls back to the stored chart when the registry isn't reachable. Rollback uses helm's own revision history.

Upgrade​

  1. Sidebar → Applications → click the release row → Upgrade
  2. The drawer opens with the current values pre-filled and the available versions in the dropdown
  3. Pick a target version (or leave the same to just re-render with new values)
  4. Edit values in Form or YAML view
  5. Click Upgrade

The operation row joins the queue; status moves pending → running → deployed. You can still click into the release detail while the upgrade runs — the page shows an "operation in progress" banner and disables actions until it finishes.

Package defaults are preserved​

For marketplace apps, an upgrade keeps the package version's default values underneath your edits — they're merged server-side, with your form/YAML edits winning over the defaults. In practice:

  • You only need to fill in the values you actually want to change; untouched fields keep the package defaults
  • A same-version upgrade (e.g. just changing one value) no longer strips sub-components the defaults enable — bundled databases and similar extras stay installed

Smart fallback when the registry is down​

If you're upgrading to the same chart + same version (e.g. just changing values), DT Edge Platform re-uses the chart bytes already stored in the helm release Secret on the cluster. No registry call needed — the upgrade works even when Harbor / the upstream registry is unreachable.

If you're changing the version, DT Edge Platform needs to pull the new chart. If the registry is down, the operation fails with REGISTRY_UNREACHABLE_VERSION_BUMP. Either:

  • Wait for the registry to come back, or
  • Pin to the current version (no version change → fallback path)

Rollback​

Two ways depending on what you want:

Helm-revision rollback​

Sidebar → Applications → release row → Detail → History tab. You'll see every revision helm has recorded with status + timestamp + changed values.

Click the revision you want to revert to → Rollback to this revision. DT Edge Platform issues a helm rollback against that revision; the resources on the cluster get reverted, and a fresh completed row joins the operation list.

Re-upgrade with old values​

If you'd rather make it look like a normal upgrade in the audit log:

  1. Open the History tab as above
  2. Click the older revision → Open in Upgrade
  3. The Upgrade drawer pre-fills with that revision's values
  4. Click Upgrade

Same end state; better audit trail (an explicit user-driven upgrade rather than an automatic rollback).

Uninstall​

Sidebar → Applications → release row → Uninstall. Confirm.

DT Edge Platform calls helm uninstall <release> on the cluster. The k8s resources for that release are removed; the helm history is cleared.

The row stays in the Applications list briefly with status uninstalled, then disappears once the next sync runs (~1 minute). If you want it gone immediately, use Force remove from list in the actions menu — it deletes the snapshot row without touching the cluster (useful when the cluster is gone but the row sticks around).

What you can't do from the UI​

  • Edit chart resources directly for a managed release. The detail page has a "View YAML" tab where you can see what's deployed; edits go through Upgrade (with new values), not free-form YAML.
  • Run a partial upgrade of just one workload. Helm operates on the whole release. Want finer control? That's the chart's responsibility — split it or use feature flags.

Common errors​

  • REGISTRY_UNREACHABLE_VERSION_BUMP — see Smart fallback above
  • OPERATION_IN_PROGRESS — another op against this release is in flight; wait or check the operations list
  • RELEASE_OWNERSHIP_FORBIDDEN — on a public edge, this release was installed by another org; they have to upgrade / uninstall it
  • Helm error: "no deployed releases" — the release was uninstalled outside DT Edge Platform. The Applications row is stale; force remove it.

See also​