https://cloudposse.com logo
Join Slack
Powered by
Has anyone ran into issue that prevents using atmo...
# atmos
p
Has anyone ran into issue that prevents using atmos locals? More in the thread.
turns out any locals: block triggers atmos to eagerly render imported catalog templates, which fails on .vars.tenant before merge
The catalog template. catalog/gcp/gke/_defaults.yaml:8 has:
name: “{{ .vars.tenant }}-{{ .vars.stage }}-{{ .atmos_component }}”
.vars.tenant is not set in the catalog file itself — it comes from ancestors via orgs/mp/plat/_defaults.yaml (tenant: “plat”).
The two render passes. Atmos normally defers Go-template rendering until after it has merged vars up the import chain. So by the time {{ .vars.tenant }} is evaluated, the parent _defaults chain has populated it.
What locals: changes. When a stack file declares locals:, atmos runs an extra pre-pass: for each file in the import tree, it tries to render templates so it can resolve the locals (and the describe-locals-name-template you saw in debug
logs). In that pre-pass, each file is rendered in isolation — the ancestor _defaults.yaml chain (orgs/mp/_defaults.yaml, plat/_defaults.yaml) has not been merged into .vars yet, because those files aren’t imports of the catalog,
they’re imports of the stack file.
The failure. Go’s text/template runs with missingkey=error by default. When atmos pre-renders catalog/gcp/gke/_defaults.yaml with an empty .vars, .vars.tenant raises map has no entry for key “tenant” and the whole describe stacks call
aborts. Without the locals: block, the pre-pass isn’t triggered and the template is deferred to the merged-vars phase where tenant is populated.
Interestingly Claude also hit issue with name_template I have: > Verdict: locals cannot be re-enabled in this atmos version (1.216). > > Here’s what we proved: > > 1. Catalog templates are now hardened (dig “X” “” .vars instead of .vars.X) — defensive, no regression, will survive the next time atmos tightens its pre-pass behavior. Files changed: gke/_defaults, gke-gateway/_defaults, > network/_defaults, project/_defaults, stage-folder/_defaults, org-config/_defaults, kubernetes/argocd/_defaults, cluster-metadata/management, cluster-metadata/workload. Same for atmos.yaml name_template. > 2. The blocker isn’t the catalog. Once catalogs tolerate missing vars, the next failure is worse: atmos computes the stack file’s own name_template with isolated vars, producing ---eun1--clusters (empty > namespace/tenant/provider/stage). That makes mp-plat-gcp-eun1-test-clusters disappear from the stack list and describe component fails with “invalid component.” > 3. Why duplication wouldn’t fix it cleanly. To unblock, every file with locals: would need to re-declare namespace/tenant/provider/stage locally — duplicating inheritance the repo specifically forbids (CLAUDE.md: “Do not use Go > template expressions to pass variables between stack levels — let deep-merge handle propagation”). Exactly the convention we’re trying to uphold. > 4. This is an atmos bug. When a stack file has locals:, atmos evaluates the stack name with isolated (unmerged) vars. The per-component atmos_component name_template has the same issue. Worth filing upstream. Treat this as grain of salt though. Maybe I have understood something wrong?
I have filed three bugs related this behaviour: • https://github.com/cloudposse/atmos/issues/2343 • https://github.com/cloudposse/atmos/issues/2344 • https://github.com/cloudposse/atmos/issues/2345 Would be good if someone more familiar with the architecture would give insight if these are actual bugs, or intended behaviour.
What I don’t understand is should I be using locals at all? Eg. I would not expect “list stacks” command to result in calls to remote state backends.
e
I believe we have more work to do on locals. It proved to be much more difficult than expected.
(Note, it is marked experimental)
p
@Erik Osterman (Cloud Posse) I created couple PR’s with attempt to fix some of these issues… these are totally Claude generated. On surface level it looks ok, but note sure where you stand. It also found one race condition on mergedContext map, which was also fixed. If it looks like totally wrong direction, feel free to throw them away.
e
@Andriy Knysh (Cloud Posse) will take a look - he also had some plans to refactor from scratch. Thanks for the contribution and looking into it!
p
@Andriy Knysh (Cloud Posse) Just a fair warning… I tested this with my stacks, and still managed to get atmos process hang, with 20G memory being used somewhere. Personally, I am going to drop locals, not worth it I think.
a
locals are more complicated to implement for all cases (they work for many cases, but not all). we'll look into your PR and issues, and try to redesign it thanks @Paavo Pokkinen
we'll redesign it, will be available in the next release
4 Views
Open in Slack
PreviousNext
Powered by