Repository navigation
Description
What is wrong?
flux-plunger temporarily sets HelmRelease.spec.suspend=true while recovering release with has no deployed releases, deletes latest Helm storage Secret, sets reconcile annotation and then unsuspends release. It does not check deletionTimestamp before starting recovery, and error between updates can leave HelmRelease suspended.
When suspended HelmRelease is deleted, helm-controller v1.5.0 skips uninstall and removes its finalizer. HelmRelease disappears, but chart resources and Helm storage Secret remain.
For VMDisk this leaves DataVolume, PVCs, CDI importer pod, RBAC and WorkloadMonitor after both VMDisk and HelmRelease are deleted, but bug is not specific to VMDisk.
How to reproduce?
- Create VMDisk with import that stays in progress, for example HTTP source returning 404.
- Wait until DataVolume, importer and Helm release Secret exist.
- Set backing HelmRelease
spec.suspend=true, reproducing state created byflux-plungerbetween its updates. - Delete VMDisk through API.
HelmRelease disappears without UninstallSucceeded. DataVolume, PVCs, importer pod, RBAC, WorkloadMonitor and Helm release Secret remain without deletionTimestamp.
Control run with spec.suspend=false ends with UninstallSucceeded and removes all release resources.
How it should work?
Deleting HelmRelease must clean release resources even when flux-plunger recovery is running. flux-plunger should skip objects already being deleted and must clear suspension it owns after any failed step.
Delete can arrive after initial deletion check, so recovery needs sequence which guarantees Helm uninstall if deletion happens between suspend and unsuspend. Regression test should cover this exact window.
Activity
fix(fluxcd): keep Helm uninstall working during flux-plunger recovery (…