DevOps Community Sponsored by Cloud Posse

SweetOps

:question:  is there an atmos native way to arbitrarily look up things from a state backend, if they aren't technically managed by your stack?

specifically just like, pointing atmos at a random state file and extracting information out of it

Not needing the song and dance of, initializing a workdir or vendoring and doing a terraform init, generating the backend configs.. etc

Trying to avoid applying a specific component because technically there's another stack managing it currently. What I could do is just have it in its own stack and use it as a reference.

Not sure if I can interact with the component if it's disabled via metadata

I see `static` backend, which I could do some weird stuff with probably..

ahhh interesting.... I play with that idea while developing the Azure keyvault support

I think what you can do, if the state is on the same cloud ( or even if is not) is to save outputs to secrets

that will work if you do not want to use the state data resource in terraform

We've been trying to move away from the ssm store hooks, because we kept getting hit with rate limits

That could be a thing, idk going to try to use the refs I need using !terraform.state if I can, this should be a temporary thing that I can rip out after we migrate everything

I used to get into that problem before but I started to save json instead so one call gives me a map of useful values

also secret manager I believe have higher rate limit and SSM has a tier I believe? ( I can't recall now)

it was more of a problem where we were using it on a bunch of different components, and running many stacks at the same time. We had a big mix of that and the old `(atmos.Component $thing .stack).outputs....`  pattern

<https://github.com/cloudposse-examples/atmos-native-ci/blob/main/terraform/stacks/deps/ecs.yaml|github.com/cloudposse-examples/atmos-native-ci/blob/…/ecs.yaml>

You can define an abstract component that represents the state of that thing you depend on

:white_check_mark:
• you can `!terraform.state` to get things off of a disabled component, I am getting a strange error though

Then refer to it as though it were managed by your stack.

I'll try that ^ -
``` INFO  Running hooks event=after.terraform.apply status=failure
 DEBU  Running hooks count=1 status=failure
 DEBU  Skipping hook, status does not match `when` hook=store-outputs when={node:<nil>} status=failure```
Not sure if this is caused by reffing a disabled component or something, maybe fresh bug

We use it actively in that working example I shared

So it's probably an edge case in what you are doing

spent way too long debugging this.. upgraded to 1.224.1, still getting errors. decided to blow away tf state in dynamodb and that fixed it

really should move over to s3 state locking

think it was a combo of running 1.224.0 and that. anyway. yeah this abstract thing now seems to be working

It could be something we haven't tested when used in combination with the (deprecated) DynamoDB for state locking 