Per-cluster Applications from the clusters appset (T6)#40
Merged
Conversation
Switch the clusters ApplicationSet from a git directory generator to a git FILES generator over clusters/*/*.yaml, so the hub's ArgoCD produces one Application PER CLUSTER instead of one per environment directory. ─── Why ─── The directory generator named one Application per env dir (clusters-<env>, reconciling every cluster in that env as a unit). That makes a per-cluster verdict impossible: clusters-production: Synced only means the whole environment reconciled, a sibling's malformed CR taints every good vend in the env, and a stale Synced reads green before a specific CR is even picked up. The appset's own header had flagged the files-generator direction as the fix. ─── What ─── Each generated Application sources exactly one CR file — directory.include scopes the source to that file — so its sync/health reflects exactly one cluster. The portal's per-cluster ArgoCD lookup Gets the Application by a deterministic name: cluster-<environment>-<name> e.g. cluster-production-spazeks where <environment> is the file's parent directory (.path.basename) and <name> is the CR's metadata.name (== the file stem). The singular "cluster-" prefix is distinct from the old env-rollup name space, so the two never collide during a rollout. The template sets no resources-finalizer, so when the ApplicationSet controller removes a generated Application (including on this generator change) it deletes only the Application object, not the Cluster CR it managed — switching generators can't itself trigger a teardown; only removing a cluster file does. repoURL, project, in-cluster (hub) destination, and prune/selfHeal/SSA syncPolicy are unchanged. Static-validated (yamllint + all kustomize overlays build); the rung-1-via-portal runbook applies this on the hub for live validation.
CI Results
All validations passed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Master plan target #6 / eks-gitops#39 — the prerequisite for portal T7 (honest per-cluster ArgoCD status).
Switches the
clustersApplicationSet from a git directory generator to a git files generator overclusters/*/*.yaml, so the hub's ArgoCD produces one Application per cluster instead of one per environment directory.Why. The directory generator named one Application per env dir (
clusters-<env>), reconciling every cluster in that env as a unit — soclusters-production: Syncedonly means the whole env reconciled, a sibling's malformed CR taints every good vend, and a stale Synced reads green before a specific CR is picked up. Portal can't honestly answer "did ArgoCD apply my cluster's CR" against that. The appset's own header had flagged this direction.What. Each Application sources exactly one CR file (
directory.includescopes the source), so its sync/health reflects exactly one cluster. Portal's T7 lookup Gets the Application by a deterministic name:<environment>= file's parent dir (.path.basename),<name>= the CR'smetadata.name(== file stem). The singularcluster-prefix never collides with the oldclusters-<env>rollup space.Safety. The template sets no resources-finalizer, so the ApplicationSet controller removing a generated Application (including on this generator change) deletes only the Application object, not the Cluster CR — switching generators can't trigger a teardown; only removing a cluster file does. There are no live cluster CRs today (
clusters/.gitkeeponly), so nothing to orphan. repoURL / project / hub destination / prune+selfHeal+SSA unchanged.The clusters-repo placeholder doc is updated to the per-cluster contract in a companion change. Static-validated (
task validate: yamllint + all overlays build); live validation is the rung-1-via-portal runbook's job on the hub.Closes #39.