Skip to content

fix(chart): make aif-ui-config survive helm uninstall - #219

Closed
leomiraanda wants to merge 1 commit into
mainfrom
fix/aif-ui-configmap-survives-uninstall
Closed

fix(chart): make aif-ui-config survive helm uninstall#219
leomiraanda wants to merge 1 commit into
mainfrom
fix/aif-ui-configmap-survives-uninstall

Conversation

@leomiraanda

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #218 (SUSEAI-1039). While fixing the ownership-adoption bug, found a doc/behavior mismatch: syncUIConfigMap's own comment claims aif-ui-config "is intentionally not deleted when the CR is removed," but nothing actually enforced that — charts/aif-ui/templates/configmap.yaml had no helm.sh/resource-policy: keep, so a plain helm uninstall (including the operator's own finalizer path) deleted it along with everything else in the release, silently losing any custom operator-connection/catalog settings on reinstall.

Fix

Add helm.sh/resource-policy: keep to the ConfigMap. Helm's own uninstall logic then skips deleting it, leaving its existing ownership labels/annotations intact — so a same-identity reinstall adopts it automatically with zero conflict, no adoption step needed at all for that path.

If the release name changes instead, Helm's ownership check still (correctly) rejects the mismatch — that case is what #218's adoptUIConfigMap handles, not this chart change. The two fixes are complementary, not overlapping: this one closes the common "uninstall/reinstall under the same name" path outright; #218 covers the cases where the ConfigMap's identity doesn't already match (self-heal, UI-created, or release renamed).

Testing

Live-verified end-to-end on a real cluster:

  • Fresh standalone install → CM created with helm.sh/resource-policy: keep + correct ownership stamps.
  • helm uninstall → Helm explicitly reports These resources were kept due to the resource policy: [ConfigMap] aif-ui-config; Deployment/Service fully removed, CM's uid/resourceVersion unchanged (same object, not deleted+recreated).
  • helm install (same release name) → adopts with zero conflict, uid/resourceVersion still identical throughout the whole cycle.
  • helm install under a different release name against the surviving CM → correctly fails the ownership check on the mismatched meta.helm.sh/release-name, confirming the boundary with fix(operator,chart): adopt pre-existing aif-ui-config ConfigMap into Helm ownership #218's fix is exactly where intended.

Test plan

  • helm lint / helm template clean
  • go build, go vet, gofmt clean (comment-only operator change)
  • Live cluster verification (see Testing above)
  • Reviewer sign-off on the UX call (uninstall preserves settings by design, going forward)

syncUIConfigMap's own doc comment already claimed the ConfigMap
"is intentionally not deleted when the CR is removed", but nothing
enforced that: configmap.yaml had no helm.sh/resource-policy: keep, so
a plain helm uninstall (including the operator's own finalizer path)
deleted it along with the rest of the release, silently losing any
custom operator-connection/catalog settings on a reinstall.

Adding the resource-policy annotation makes the ConfigMap survive
uninstall with its ownership labels/annotations intact, so a
same-identity reinstall adopts it with zero conflict and zero manual
intervention — verified live end-to-end (uninstall -> reinstall keeps
the exact same object, no ownership error).

If the release identity changes instead (different release name),
Helm's ownership check still correctly rejects the mismatch; that
case is handled by the aif-operator's own pre-install adoption step
(SUSEAI-1039, PR #218), not by this chart.
@leomiraanda

Copy link
Copy Markdown
Contributor Author

Folding this into #218 per feedback — both fixes belong in the same PR since they're complementary parts of the same SUSEAI-1039 story. See #218 for the combined change (commit 63910d8 carries this fix's diff).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant