https://cloudposse.com logo
Join Slack
Powered by
Is there a way for atmos to gracefully handle doin...
# atmos
z
Is there a way for atmos to gracefully handle doing a terraform state lookup on a stack reference that doesn't exist? Running into an error from one of our values that we are importing and actually overwriting
We have the 
//
default set up, but in this case we're templating something out in an 
atmos.Resolve
that doesn't actually exist 😑
e
Have you looked into using mocks?
We have a formal concept now for mocks
it requires calling with 
--use-mocks
z
We are running into this with an apply command
Atmos is trying to resolve a 
!terraform.state
lookup on an import, resolving it into a stack that doesn't actually exist, but we are also overriding this specific variable in our stack. I've worked around this by not importing that file and duplicating the file and overriding that one variable that is causing issues. We're in a transitional stage right now with implementing a bunch of these new features.
I could probably do some more whacky templating but probably don't want to
e
When. you pass 
--use-mocks
,
Copy code
Both !terraform.state and !terraform.output resolve from vpc.mocks. The familiar output and YQ-expression syntax stays the same; only the source of the value changes.
Isn't that what you need?
It eliminates the class of errors/problems
z
Guardrails keep normal operations normal
Mocks are opt-in. Without 
--use-mocks
, existing 
!terraform.state
and 
!terraform.output
behavior is unchanged.
The flag is supported by:
• 
atmos terraform plan
• 
atmos describe component
?
e
We could expand it to apply, but it's very odd to apply a mock value
z
in our case it's not really a value that would end up in the final merged yaml. It's something that atmos can't evaluate at all because the lookup isn't real
Just another layer of defaults..? Not really a mock I guess. Not sure.
e
But it's only a "default" until that thing exists; then after it exists, you want to use the remote value.
z
Something I have seen is when you try to consume a variable that doesn't exist atmos will set the value to <no value> or something
if it could do that atleast, that would unblock from this error?
e
Maybe, but also it is nefarious; e.g. you start seeing the literal no value in tags 😃
We've started making sure atmos degrades gracefully for UI output (E.g. lists)
but that's just informational; no harm in outputting 
<no value>
or similar
it's like when terraform says value only known after apply
z
usually when I see <no value>, because I've banged my head into atmos for so long now, I'm able to determine yeah I must have missed something 😂
<empty lookup>.. maybe something more specific idk
¯\_(ツ)_/¯
e
Is the component you are applying using the 
!terraform.state
as a var; or is it just the presence of the 
!terraform.state
in the stack file causing grief
z
kms_master_key_arn*:*
*'*{{ atmos.Resolve (printf
!terraform.state cloudposse-kms-key %s-%s ".key_arn // ""default"""` .vars.app .vars.account_name) }}*'*` in my case 
.vars.account_name
is set to something and templating to a stack that isn't real, so it doesn't make it to the 
// ""default"""
. This is in a 
_defaults.yaml
that is imported, and overridden, meaning this value that atmos is trying to evaluate won't make it to the inputs to the component anyway, in this specific case.
Can think of a few solutions to work around this in our codebase
I think the right solution for me in this case is just to change the default to something that atmos will always try to evaluate, removing the stack input from the template
e
Have you tried:
Copy code
kms_master_key_arn: !terraform.state cloudposse-kms-key {{ .<http://vars.app|vars.app> }}-{{ .vars.account_name }} '.key_arn // "default"'
2 Views
Open in Slack
PreviousNext
Powered by