Installer: adopt existing tracebloc-data-plane PriorityClass when workspace name changes

[saadqbal]

Symptom

Re-running the installer with a different workspace name than a previous install fails at helm upgrade --install with:

Error: unable to continue with install: PriorityClass "tracebloc-data-plane" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "ap-workspace": current value is "arturo-local"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "ap-workspace": current value is "arturo-local"

Reported by an operator (Arturo) on 2026-05-26 — first install used workspace arturo-local, second install used ap-workspace.

Root cause

PriorityClass is cluster-scoped. The chart correctly annotates it with helm.sh/resource-policy: keep (client/templates/priority-class.yaml:11) so helm uninstall doesn't yank it out from under sibling releases. But Helm's other side of that coin is: when a release with a different name tries to render the same cluster-scoped resource, Helm refuses to "adopt" it because the stored ownership annotations (meta.helm.sh/release-name, meta.helm.sh/release-namespace) don't match.

Result: a perfectly normal "I want to rename my workspace" flow becomes a hard failure with a Helm-shaped error message that the target user (an ML operator running a one-line installer) has no realistic way to diagnose.

Current workaround

Three manual options, none discoverable from the installer output:

1. Re-use the same workspace name as the previous install.
2. Re-stamp the PriorityClass ownership annotations to match the new release name + namespace, then re-run.
3. helm uninstall <old-release> + kubectl delete priorityclass tracebloc-data-plane, then re-run.

Proposed fix

Have install-client-helm.sh detect the case before helm upgrade --install and adopt the existing PriorityClass automatically:

# In install-client-helm.sh, before the helm upgrade --install call:
if kubectl get priorityclass tracebloc-data-plane -o json 2>/dev/null \
   | jq -e '.metadata.annotations["meta.helm.sh/release-name"]' >/dev/null; then
  existing_release=$(kubectl get priorityclass tracebloc-data-plane \
    -o jsonpath='{.metadata.annotations.meta\.helm\.sh/release-name}')
  if [[ "$existing_release" != "$TB_NAMESPACE" ]]; then
    log "Adopting existing tracebloc-data-plane PriorityClass (was owned by '$existing_release')"
    kubectl annotate --overwrite priorityclass tracebloc-data-plane \
      "meta.helm.sh/release-name=$TB_NAMESPACE" \
      "meta.helm.sh/release-namespace=$TB_NAMESPACE"
    kubectl label --overwrite priorityclass tracebloc-data-plane \
      app.kubernetes.io/managed-by=Helm
  fi
fi

Safe because the chart re-renders identical PriorityClass content regardless of which release "owns" it — only the ownership annotations differ, and Helm only inspects those.

Acceptance criteria

• Re-running install-k8s.sh (or install.sh) with a new workspace name when a previous workspace exists succeeds without manual kubectl intervention.
• Adoption is logged so operators can see what happened.
• No regression in the green-field case (no pre-existing PriorityClass).
• Same logic added to install.ps1 / install-k8s.ps1 if PowerShell installer follows the same flow.
• Helm chart test covers the "PriorityClass already exists, owned by a different release" path (probably via a helm template + manual kubectl apply setup, since helm-unittest can't simulate cluster state).

Notes

• Same problem will recur for any other cluster-scoped resource the chart introduces in the future (ClusterRole, StorageClass with helm.sh/resource-policy: keep, etc.). Worth factoring the adoption logic into a small helper that takes (kind, name) as args so future cluster-scoped resources can be added to the list without re-implementing it.
• The chart's helm.sh/resource-policy: keep choice is correct and should stay — this is purely an installer-side fix.

[LukasWodka]

Reproduced live in prod (2026-06-02) — 2nd occurrence

During a fresh prod-install validation on macOS (Apple Silicon), installing workspace jun2 onto a cluster that already had workspace ingdemo failed with exactly this ticket's symptom:

PriorityClass "tracebloc-data-plane" … cannot be imported into the current release:
release-name must equal "jun2": current value is "ingdemo"

Everything else in the install worked end-to-end (preflight, cluster, cred verify, pods → Connected); this was the only blocker. First occurrence was Arturo's arturo-local → ap-workspace. So it's a real, recurring workspace-rename-on-an-existing-cluster failure. (A fresh cluster avoids it, which is why the eventual prod install succeeded after deleting the cluster.)

Two candidate fixes — leaning toward (B), to be decided later

(A) Auto-adopt (the original sketch above): before helm upgrade --install, if the PriorityClass is owned by a different release, kubectl annotate --overwrite it to the current release so Helm adopts it.

• ⚠️ Concern: this silently re-stamps ownership of a shared, cluster-scoped resource to "whichever workspace installed last." Harmless on a single-workspace box, but if a cluster ever runs >1 tracebloc workspace, ownership would bounce between releases on each install, and uninstalling the "owner" later gets messy. It papers over a real sharing question.

(B) Explain and let the user decide (preferred — matches the installer's existing "warn + remedy" pattern: the daemon-won't-start hint, the 0.0.0.0 normalize warning, the bad-creds messaging). Catch the specific Helm failure and translate the cryptic error into a clear message + options. No kubectl, no silent state change.

Proposed message:

✖ This cluster already has a tracebloc workspace ("ingdemo") that owns a shared,
  cluster-wide setting (the tracebloc-data-plane PriorityClass), so installing a
  new workspace ("jun2") can't take it over automatically.

  Pick one, then re-run the installer:
  • Keep the existing workspace — re-run and enter "ingdemo".
  • Hand it to this workspace (only if you're replacing "ingdemo"):
      kubectl annotate --overwrite priorityclass tracebloc-data-plane \
        meta.helm.sh/release-name=jun2 meta.helm.sh/release-namespace=jun2
  • Remove the old workspace first:  helm uninstall ingdemo -n ingdemo

  It's shared by every workspace on this machine, so the installer won't
  reassign it for you — your call.

Mechanism (B): small enhancement to the existing helm upgrade --install failure branch in scripts/lib/install-client-helm.sh — detect the signature (cannot be imported + PriorityClass + the ownership keys) in the captured Helm output, extract the current owner, print the block above instead of the raw dump, exit cleanly. ~15 lines, no state mutation, fully unit-testable.

Deeper option for later: stop making the PriorityClass release-owned at all (install it unmanaged / as a separate shared resource / pre-install hook) — removes the conflict entirely, but it's a chart redesign and a separate decision.

---

Status: parked in Backlog — approach to be decided later. Not blocking: the fresh-cluster path avoids it, and kubectl annotate … release-name=<new> is the manual workaround today. The ticket title says "adopt"; if (B) wins, retitle to "explain … and let the operator choose."

[LukasWodka]

2026-07-12 backlog-bug review — closing as superseded by the v1.4.5 redesign.

PR #192 (merged 2026-06-04, commit 36b78e4 — its message names this collision as the motivation) removed the failure mode wholesale: priorityClass.create defaults to false (values.yaml:424-427 on develop AND main → the template renders nothing → no Helm ownership import can occur), and the workspace-name prompt was removed entirely (fixed namespace + the one-per-machine guard). For the explicit opt-in case on a multi-release cluster, the commit documents create: false + name: <existing>.