chore(argo): delete the Argo CRDs and the RBAC that only Workflows used #462
Loading…
Reference in a new issue
No description provided.
Delete branch "sean/retire-argo-crds"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Eleven CRDs -- three Argo Events, eight Argo Workflows. The three ArgoCD CRDs share the argoproj.io group and stay; 28 live Applications need them. The crds Flux Kustomization is prune: false on purpose (its own comment: CRITICAL, never prune CRDs), so a tombstone Job does the delete with the eleven names pinned in resourceNames, and it WAITS up to fifteen minutes for both controllers to be gone rather than refusing, so this can be released alongside the controller retirement. Also fourteen RBAC objects that existed only to run a Workflow pod, including a standing flux-system write grant held by an unused ServiceAccount. binjovi-deploy-argocd stays: it shares their naming but the live native binjovi-argocd-agent runs as it, and the tombstone cannot reach it. While rewriting the guard: every '! grep' refutation in tests/binjovi-argo-execution.sh was INERT, because bash's set -e does not fire when a return value is inverted with '!'. They now go through a helper that exits -- which caught a mistake in this very commit on its first run. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76
RELEASE THIS AFTER the controllers are gone, not with them. Both tombstones here refuse until they are, but the ordering is real: a CRD deleted while its controller still watches it wedges on a finalizer. ELEVEN CRDs. Three from Argo Events, eight from Argo Workflows. The three ArgoCD CRDs share the argoproj.io group and stay -- 28 live Applications need them. The `crds` Flux Kustomization is prune: false and says why in its own comment ("CRITICAL: Never prune CRDs to prevent data loss"), so removing the files stops Flux re-applying them and nothing more; a tombstone Job does the delete, with the eleven names pinned in `resourceNames` so RBAC is the fence whatever the script says. Removing workflows.argoproj.io garbage-collects the 64 finished Workflow records and their pods, on purpose. FOURTEEN RBAC OBJECTS. Three ServiceAccounts with no running pod, four `*-executor` RoleBindings bound to a Role the Argo cascade deletes, Role/RoleBinding binjovi-deploy-flux in ns flux-system -- a standing write grant on Flux objects held by an account nothing uses, while the native flux agents have their own -- and five binjovi-argo-* CiliumNetworkPolicies that select isolation labels NO RUNNING POD carries. THE ASYMMETRY IS THE RISK. binjovi-deploy-argocd was created for Argo like all of them and shares their naming, but the live native binjovi-argocd-agent pod runs as it. It stays; its `-executor` RoleBinding does not. The tombstone cannot reach it -- it is absent from every resourceNames list -- and the Job asserts it is present before and after. `binjovi-control-workflows` keeps its pod and log reads and loses its `argoproj.io/workflows` rule, which is standing privilege on a kind that no longer exists. The file is renamed to what it now is: native-deploy-rbac.yaml. GUARDS. `tests/binjovi-argo-execution.sh` was two guards in one. Its second half pins the live Kyverno credential policy that protects the package and RPG lanes, so it survives as tests/binjovi-untrusted-credential-guard.sh; the first half is replaced by assertions that the retired names cannot return. While rewriting it: every `! grep` refutation in that guard was INERT. Bash documents that `set -e` does not exit "if the command's return value is being inverted with !", so a dozen refutations reported nothing and passed whatever the file said. They now go through a `refute` helper that exits. It caught a mistake in this very commit on its first run -- an over-broad refutation of `apiGroups: [argoproj.io]`, which ArgoCD Applications also need. tests/argo-crds-retired.sh and tests/binjovi-argo-rbac-retired.sh pin the rest, each with negative controls: an ArgoCD CRD inside the delete grant, a removed controller pre-check, a deleted ArgoCD CRD file, a grant widened to the live agent's ServiceAccount, an unpinned rule, and a dropped post-condition each turn a guard red on its own. `tests/argo-workflows-crds/run-all.sh` pinned the v4.0.8 CRD schemas by digest and goes with them, along with its entries in run-all.sh and every-guard-has-a-caller.sh. Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA761b8663a48ato316e18d1f5Pull request closed