-
-
Notifications
You must be signed in to change notification settings - Fork 981
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency optimization broken since version 0.55.4 #3441
Comments
Hey @mickeder Terragrunt does have to fetch dependencies recursively, as ancestor dependencies can influence outputs of immediate parents. It should be caching the outputs of ancestor dependencies to minimize the performance penalty, however. Have you done a performance analysis to see what the impact has been in the latest version of Terragrunt? You can take advantage of the OpenTelemetry integration to get more insight on that: |
Hi @yhakbar, as I stated in my report, I tested it with the newest version of Terragrunt. It doesn't matter which version I use, after version 0.55.3 outputs of all ancestor dependencies are fetched, even though it was not the case before. The current behavior is also not reflected in the documentation that I mentioned (Can I speed up dependency fetching?), which states: In my opinion, the new feature implemented in version 0.55.4 giving the ability to reference inputs of dependencies broke the previous behavior and was not designed to change this in the first place. |
I've noticed the same performance degradation, a job that used to take 1-2min and build 2 dependencies, now takes 5mins+ and builds 14 dependencies. Most of my colleagues stopped updating last year and have been using a version around v0.51.7 |
I have experienced the same issue, some runs that used to take seconds now take many minutes, and then breaks. This is quite a critical bug |
+1 |
@denis256 ProofWhen I with v0.55.3 with v0.55.4 with v0.55.5 with v0.55.6 Tested on
A fix would be greatly appreciated, as our production dependency graphs are significantly larger than the ones used in these tests. |
Hello, I would like to ask you if the #3461 can be prioritized since we are also impacted by this performance degradation due to broken optimization for dependencies. |
Hi all, this is also an issue for us. I'm not an expert, so more of an anecdotal experience: I tried to download TG v0.55.3, but couldn't find it any longer. |
https://github.com/gruntwork-io/terragrunt/releases/tag/v0.55.3 FYI, you can find any release of Terragrunt by punching in the value into the URL, even if it doesn't show up in GitHub releases search for whatever reason. We are actively investigating this issue. Performance improvements require a lot of testing and validation, so please have patience as we make sure this issue is resolved. |
Thank you, and I promise I searched for the specific version and github search didn't drop this out :\ edit: quick update, for some reason 0.55.3 cannot even produce a stable plan (cannot find included files, which are working with 0.68.0, I believe we have some other issues as well, so maybe this is a mini red herring for us. |
Hello,
https://github.com/gruntwork-io/terragrunt/releases/tag/v0.68.5-beta2024102101 Let me know if this approach improve performance on real projects |
@denis256 thank you for this fix. I tested it out with our real environments with below command:
The time of dependency outputs reading improved a lot, in this example from over 3 minutes to under a minute. However, I have a reservation to the implementation of the
Therefore I suggest adding a separate flag |
@denis256 thanks for the fix. I also tested for our stack and now it's sub 7 mins for plan with initialised TG modules. 🥳 |
I can confirm the fix improved enormously the performance. Looking forward to see in stable release. |
Initial optimization included in https://github.com/gruntwork-io/terragrunt/releases/tag/v0.68.5 Optimization can be enabled with |
Describe the bug
Recently I've noticed that newer versions of Terragrunt run very slow when there are many recursive dependencies. This was not the case in the past, and I pinpointed the version where it changed to 0.55.4 - the introduction of
Reference to dependency inputs
.According to the documentation about dependency block, there is a way to fetch only the outputs of the lowest level dependencies by using
remote_state block
. This way the outputs are not fetched from any higher level dependencies.Unfortunately, this behavior was broken with the introduction of referencing dependency inputs in version 0.55.4. Currently all the outputs are fetched recursively for all dependency levels, which takes a long time when the dependency graph is complex but in reality only the lowest level dependency output is required for the root module.
Steps To Reproduce
Given below minimum configuration structure, I was able to reproduce the improper behavior.
After applying
module-a
andmodule-b
, I ranterragrunt plan
formodule-c
with version 0.55.3, which gave the following debug logs:Then I ran the same command with the newest Terragrunt 0.67.13, and the debug logs clearly show that outputs of
module-a
were fetched as well, even though they are not required bymodule-c
.Expected behavior
Terragrunt should not fetch dependency outputs recursively, but just for the immediate dependency that is required. Basically the behavior from version 0.55.3 should be restored, but taking into consideration the newer feature of referencing dependency inputs as well.
Nice to haves
Versions
Additional context
We use Azure
remote_state
and dependency graphs as below are not uncommon. This causes the dependency fetching part take several minutes instead of several seconds.The text was updated successfully, but these errors were encountered: