hello, wondering what happens if you're using `!te...
# atmos
b
hello, wondering what happens if you're using
!terraform.state
and the component/stack you're querying for doesn't exist yet, or hasn't been applied yet?
j
try using mock outputs with YQ expression. that ensures that there's a placeholder value to prevent plans from failing
this 1
p
I use defaults also with // that way a
fake
value is injected and by the time is applied the real value is used or until the next run.
👍 1
the problem with fake values is that can cause errors so I think the best is to use go templates or
.var.something
to concatenate the string of the values to get the output
j
@John Dutchover fyi ^^
b
thank you for the input @Jonathan Rose. What about situations like trying to plan and terraform is making API calls to an EKS cluster that has not been applied yet?
j
can you give an example?
are mock outputs giving an error?
b
let me see if I can find an example, but the gist of the problem is that we have a stack setting up an EKS Cluster, and a stack that bootstraps parts of our cluster, like configuring ArgoCD which relies on the k8s provider and the plan has a fit because it tries to make API calls to a cluster that hasn't been built yet
so we can mock outputs all day long, but if the API call fails, the plan fails
j
EKS is a messy one - I think we have issues like that too because of the k8s provider.
👀 1
b
I haven't tried this myself yet. However I'd hope it's a loud and clear error message that the state file doesn't exist? What is the behavior you've observed?
j
I haven't done EKS in atmos yet. There was some WIP that got shelved but the goal was the leverage atmos so that there would be a clear separation between between using Terraform and Helm to avoid messy dependencies that couldn't be fixed by mocked outputs
b
I've managed to get atmos to run a plan, but I control the dependent layers by setting a bool that checks if previous layers were deployed. If they haven't been deployed, then the layer is disabled. I might leverage a cross between atmos workflows and github workflows to ensure the plans run only once the previous layers have been deployed
👍 1
in our case, we run plan, present the plan in the pr, then it gets reviewed and then after merge we just apply those components with auto approve