yorinasub17
commented
4 years ago That's a fair point. This happens because getting the output calls RunTerragrunt here, and that function is currently parsing the target config in full.
The implementation to fix this is a bit involved though because it means we need to update the RunTerragrunt routine to do "just-in-time" config parsing. That is, it needs to index all the terraform commands and construct a mapping so that it only parses the relevant pieces of the config for each command. E.g., output may only need the terraform block, while apply needs all the inputs, unless it has a plan file (you can see how this can get complicated).
Note that we can't just parse out the terraform block for calling output and be done with it. The crux of the issue is parsing out the dependency blocks from the target config, and avoiding that requires an update to the configuration parsing mechanism. Right now, we parse dependency blocks before terraform blocks (see https://terragrunt.gruntwork.io/docs/getting-started/configuration/#configuration-parsing-order) because we want to support the usage of dependency in setting hooks and extra_arguments and the like. Updating that means we need some kind graph based parsing mechanism so that we only parse dependency blocks if it is used: a very involved refactor!
I'd be willing to overhaul the configuration parsing mechanism, but right now we are buried with other initiatives to take on this. If anyone else in the community wants to take a crack at this, please submit an RFC detailing the approach given the changes involved.
dmattia
Current behavior
If I have a module named MainModule with two dependency blocks, and those two dependencies each depend on a few other modules, and I run a
terragrunt planon MainModule, terragrunt will run aterraform output -jsonto check the state of all modules described in this scenario, not just on the two top level dependencies.What I don't love about this
It is slower
In my real world terragrunt config, we have hundreds of modules, some of which have over a dozen dependencies, each of which have their own. Even with provider caching, I still see cases where a
terragrunt plantakes over ten minutes because it checks all of the state in series without parallelization.It goes against my intuition of the permissions model
This one is highly opinionated, so I only mean it as a suggestion. But say I have the following modules:
Running a plan on EcsDevModule would have a deep level dependency on being able to access the Prod env state, which I do no like. Instead, I would prefer if I only had to give access to CommonsOrg state.