argocd/apps/platform/appset.yaml's clusters generator now requires both purpose: platform and argocd-active: "true" (see PR #17, following terraform ADR 0003). The argocd-active label is applied only by terraform (clusters/dieubernetes-platform-do-atl1/main.tf, kubernetes_secret.argocd_cluster), and isn't tracked anywhere in this repo.
Risk: if the platform cluster's self-registration secret is ever recreated (terraform destroy/apply cycle, or a future re-bootstrap) without someone remembering this label lives in terraform, the selector silently matches zero clusters. With prune: true, that means kargo and kargo-pipelines (and cluster-registrations itself) get pruned with no warning.
Flagged by Copilot review on PR #17:
Tightening the clusters generator selector to require argocd-active: "true" will cause the platform ApplicationSet to generate zero Applications if the platform cluster secret is missing that label... it would be safer to manage/apply it via GitOps in-repo (or otherwise document the dependency clearly) so the platform rollout doesn't silently stop when cluster secrets change.
Managing the label via GitOps in-repo doesn't fit cleanly here - it's deliberately terraform-owned per ADR 0003, since git can't be the source of truth for "which platform cluster is active" without the planned failover Cloudflare Worker's git write-back, which doesn't exist yet.
At minimum this needs documenting somewhere a future reader would see it before touching either the appset or the terraform resource. Possibly also worth a safeguard (e.g. a CI check or ArgoCD notification) that alerts if the platform appset ever generates zero Applications.
argocd/apps/platform/appset.yaml's clusters generator now requires both purpose: platform and argocd-active: "true" (see PR #17, following terraform ADR 0003). The argocd-active label is applied only by terraform (clusters/dieubernetes-platform-do-atl1/main.tf, kubernetes_secret.argocd_cluster), and isn't tracked anywhere in this repo.
Risk: if the platform cluster's self-registration secret is ever recreated (terraform destroy/apply cycle, or a future re-bootstrap) without someone remembering this label lives in terraform, the selector silently matches zero clusters. With prune: true, that means kargo and kargo-pipelines (and cluster-registrations itself) get pruned with no warning.
Flagged by Copilot review on PR #17:
Managing the label via GitOps in-repo doesn't fit cleanly here - it's deliberately terraform-owned per ADR 0003, since git can't be the source of truth for "which platform cluster is active" without the planned failover Cloudflare Worker's git write-back, which doesn't exist yet.
At minimum this needs documenting somewhere a future reader would see it before touching either the appset or the terraform resource. Possibly also worth a safeguard (e.g. a CI check or ArgoCD notification) that alerts if the platform appset ever generates zero Applications.