Hi everyone. I'm new to atmos and there is one quirck I cannot figure out and didn't find straight answer in the docs. I'm mainly working with public modules from the terraform registry, that aren't cloud posse modules. That means they don't have the context variables: namespace, tenant, environment, stage. What is the best practice of adding those variables to the module automatically, without causing a drift to the existing module if I pull a new version?

@Elon yes, if you are using other modules/components, they don't have the context variables (namespace, tenant, stage, etc.). If you add them as global Atmos variables to the Atmos stack, it will work, but Terraform will show warnings about providing values for the variables that are not declared in the modules. You can add the variables to the modules automatically using Atmos `generate`: • https://atmos.tools/cli/commands/terraform/generate/ • https://atmos.tools/cli/commands/terraform/generate/files • https://atmos.tools/cli/commands/terraform/generate/varfile Although you don't need to do all of that. You can use any of the following instead: • In your

stacks.name_template

in

atmos.yaml

, don't use templates with

vars

, use templates with, for example,

settings

(use

settings

to define your stack names). See https://atmos.tools/cli/configuration/stacks/#stack-naming-with-name_template-recommended

name_template: "{{ .settings.context.environment }}-{{ .settings.context.stage }}"

This way, you don't use the global context variables in your stacks, and they are not snet to Terraform by Atmos

But let's reset here

Hello @Erik Osterman (Cloud Posse) and @Andriy Knysh (Cloud Posse) I'd like to hear your thoughts on this: For me the context shouldn’t be passed implicitly to the component but explicitly in the

vars

field (explicit > implicit). This would eliminate the need for all these workarounds (to me this seems more like a "Cloud Posse setting" that’s enabled by default). To give an example, when I started to use Atmos I configured stack naming to include the

cloud

variable (e.g.,

aws-core-identity-euw3

), a variable I don’t need anywhere in the components, it’s only useful for the stack name. But I have to add it everywhere just because it’s inherited. As a beginner, it's a bit disturbing and goes against a great Atmos feature: its versatility. Personally, having an option to enable or disable this automatic inheritance is, I think, the feature I’d like to see most. That reminds me I have not posted any feedback on Atmos but here's at least a little bit. Hope this helps.

This is helpful. The origin of this is an early opinionated decision that predates atmos: Programmatically enforced naming convention. This is why we have the null label module.

The origin of this is an early opinionated decision that predates atmos: Programmatically enforced naming convention

I know. circa 2016 I used Cloud Posse Terraform components and context was already there 🙂.

Would this have been easier for you?

I saw that but not sure to understand your point. Is it to use explicit name from stack manifest? 'Cause

name_template

or

name_pattern

have the same behavior: context is passed.

you would like to be able to disable inheritance?

Disable name pattern variables? I think yes. I find it clunky to systematically add a context file to every component. I think I’d rather add three lines to the vars (e.g. region, tenant, stage). Since, in many cases, tenant and stage are only needed for tags and will therefore be placed directly in the tags variable. I think it's the explicit nature of it that I like. But perhaps a more elegant or useful solution is possible? Maybe the explicit name is the solution. I admit that this was my first thought, but I haven’t had time to revisit it since (I'm still a newbie. Atmos is powerful and offers a lot of possibilities).

Does that also mean disabling imports?

For now, I use only import for mixins variables, so to me no.

@Yota so now, you can be explicit about every stack name.

name: exactly-what-i-want-it-to-be

Thank you kindely for your answers. I'll try it out.