Is there guidance for using

!terraform.state

vs

atmos.Component

? I’m struggling to understand the differences based on the documentation. This week, we uncovered that

atmos.Component

was breaking one of our stacks (it was causing terraform workspace to flap during plans which ultimately caused the apply step in Spacelift to fail). When we changed the offending catalog files to use

!terraform.state

syntax instead, things began working again. Given component_A and component_B, the spacelift stacks for component_B were failing when: •

catalog/component_A/defaults.yaml

-> had

atmos.Component

templating to fetch outputs from

component_B

•

component_B

-> uses

remote-state

module to query outputs from

component_A

This seems to be not an issue after we switched to

!terraform.state

syntax..

Maybe this is helpful https://atmos.tools/stacks/sharing-state

please take a look: https://atmos.tools/stacks/sharing-state https://atmos.tools/stacks/sharing-state/terraform-state

The key thing is

{{ … }}

is not a YAML thing, we preprocess it and do interpolation. The result must be valid YAML.

we don't recommend using https://atmos.tools/functions/template/atmos.Component b/c it calls the terraform binary (

terraform output) and is much slower than the YAML function

Gotcha. I understand that

!terraform.state

is the latest and greatest, but wanted to understand more about why

atmos.Component

broke our setup. I guess atmos.Component is not mentioned anywhere in the Sharing State docs y’all linked, but maybe y’all are just trying to steer eyes away from it.

The

!something

is native YAML explicit tags that are evaluated during YAML processing and results are injected directly into the object. This is more reliable that string manipulation. If the result of

atmos.Component

is not valid yaml it could break.

In our case the results of atmos.Component was just a plain string, though I suppose that’s not valid YAML.

(Ya we are trying to steer everyone away from

atmos.Component

because it is error prone)

> Strings in YAML can be tricky Don’t i know…

@Sean Nguyen

atmos.Component

is a template function. Not that it's bad in itself, it has two main issues: • You have to use Go templates, which can produce invalid YAML (which is very difficult to guarantee to not to) • It calls

terraform output

which in itself is very slow (not an Atmos issue per se, it's how terraform works) • B/c of the above,

atmos.Component

is not actively maintained (use the YAML functions instead). And b/c it's not actively maintained, something probably broke. Is it only in Spacelift? Local execution is OK?

LOL woops. Didn’t realize Tyler had already posted.

ok, so it's the same issue 🙂 thanks, we'll look into it

Yep. Tyler tipped me off on the

!terraform.state

change. Anyways, thanks for the help @Andriy Knysh (Cloud Posse) (and @Erik Osterman (Cloud Posse))! Long time no talk --hope y’all have been well.

it works locally w/o issues at all?

Locally it’s not an issue because

atmos terraform apply

and

atmos terraform deploy

don’t rely on a saved plan file. It’s all one atomic

terraform apply [-auto-approve]

under the hood as I understand it.

Because the apply step in spacelift relies on the previously generated plan file, the apply failed due to a broken lineage..

Yes,

atmos.Component

and

!terraform.output

would likely have problems, also anything that relies on backend generation. Moving to

!terraform.state

definitely the right move, since it talks to S3 directly.

Any tips for getting

!terraform.state

and other YAML functions to play nice with our YAML linter?

check yaml.........................................Failed
- hook id: check-yaml
- exit code: 1

could not determine a constructor for the tag '!terraform.state'
  in "stacks/catalog/iam-delegated-roles/defaults.yaml", line 118, column 32