Hello. I’m working with Terragrunt using Atlantis. Infrastructure is layered and there are groups of modules which normally should be applied one by one. For example first need to create VPC. Second - EKS, third - something on top of EKS (some EKS addon) e.t.c This can be achieved by: 1. terragrunt plan/apply for whole project 2. terragrunt plan/apply using terragrunt-atlantis-config where executable modules are applied granularly in order defined using Terragrunt dependency blocks First option isn’t OK for many reasons, second option is fine - modules are planned and then applied in order, however when merge request contains changes in module A and module B where B has dependency from module A outputs, and those outputs should be changed, there is a situation when

atlantis plan

creates plan file for module A which is actual, but plan file for module B has outdated outputs of module A and

atlantis apply

will lead to undesirable behaviour Possible solutions are: 1. to accept such behaviour and keep in mind that modules need to be orchestrated by user taking it into account. Make changes for modules group A, get request approved, run

apply

, make changes for modules group B, get approved, run

apply

and so on. But it’s silly, requires to keep all context in a head and sometimes a lot of efforts to setup new infrastructure unit where there can be many layers of infra 2. declare workflow where

atlantis apply

will do will do

terragrunt plan

and then

terragrunt apply

, but such approach is also no-go, because

atlantis apply

doesn’t guarantee correctness, because there may arise a situation where another changes will be applied, not those which were planned during

atlantis plan

I’m wondering if someone has encountered with that and are there other options (for example possibility to apply execution order group separately and prevention of apply or execution order group if it wasn’t planned with applied dependencies) which may help? Thanks

This sounds more of a design decision than an actual problem. I think if you were to rely in data lookups for things that module A created of rmodule B then you will get an apply error that you can rerun once module A is applied , but as you said that implicit dependency order needs to be kept so you will have to do 2 PRs

I’m using execution order groups, terragrunt-atlantis-config generates atlantis.yaml for me using pre workflow hook in accordance with Terragrund dependency blocks. In case of

atlantis plan

where I have changes in module A from execution group 1 and module B from execution group 2 -

atlantis plan

executes all modules in order, but in resulting plan file module B has variables from outputs of unapplied module A, because module A should be applied before module B planned. Also in this case module B apply not necessarily ends up with failure - it applies normally, but with outputs which it shouldn’t be applied @PePe Amengual

monorepo?

If they are in the same repo, why not let terraform figure out dependencies and order of modules? And if there are no explicit dependencies between some modules, you can always add

depends_on

?

This is more of a terragrunt issue. We have the same problem and there is no easy solution. The dependency result reads from terraform state that is only updated after apply, so we split PRs or run plan/apply/plan/apply (horrible I know) to overcome this.

@PePe Amengual yes, monorepo

you can always add

depends_on

@Stas Ostrovskyi It could be possible to add support of

depends_on

to terragrunt-atlantis-config, but

depends_on

should prevent planning module if its dependencies weren’t applied to resolve issue (currently it prevents applying only from what I see in docs) @Gabriel Martinez yes, and sometimes it breaks things

mmm if you depend on reading the remote state of every module, then hell starts there, I never liked that approach much. I always recommend people to move to Data lookups over Parameter store values or any other key value and have strong naming convention so you can find anything at any stage

How does this help to build guardrails around execution order, when you need to apply several groups of modules one by one?

it actually does not but enforces the relationship so you change the development flow around it

it actually does not but enforces the relationship so you change the development flow around it

Hm… Where could I find out more about such approach?

look at cloudposse terraform modules and look at Atmos and the terraform-aws-components repo