Prune unused resources from graph #2775
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
| // Do a depth first walk from the leaves and remove things. | ||
| return g.ReverseDepthFirstWalk(leaves, func(v dag.Vertex, depth int) error { | ||
| println("NAME: " + v.(dag.NamedVertex).Name()) |
|
Clarified that comment, will merge shortly after tests pass. |
|
(force pushed with a rebase on master to verify that tests still pass with latest core changes) |
|
LGTM |
phinze
added a commit
that referenced
this pull request
Jul 20, 2015
Prune unused resources from graph
phinze
added a commit
that referenced
this pull request
Jun 12, 2016
For `terraform destroy`, we currently build up the same graph we do for `plan` and `apply` and we do a walk with a special Diff that says "destroy everything". We have fought the interpolation subsystem time and again through this code path. Beginning in #2775 we gained a new feature to selectively prune out problematic graph nodes. The past chain of destroy fixes I have been involved with (#6557, #6599, #6753) have attempted to massage the "noop" definitions to properly handle the edge cases reported. "Variable is depended on by provider config" is another edge case we add here and try to fix. This dive only makes me more convinced that the whole `terraform destroy` code path needs to be reworked. For now, I went with a "surgical strike" approach to the problem expressed in #7047. I found a couple of issues with the existing Noop and DestroyEdgeInclude logic, especially with regards to flattening, but I'm explicitly ignoring these for now so we can get this particular bug fixed ahead of the 0.7 release. My hope is that we can circle around with a fully specced initiative to refactor `terraform destroy`'s graph to be more state-derived than config-derived. Until then, this fixes #7407
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2766
This is a hammer approach to fixing #2766. I feel compelled to explain why such a change is necessary.
The issue with #2766 is that we're interpolating a module variable during a destroy plan. As such, of course, the interpolation fails (because the data it is interpolating is from a resource that has been destroyed).
In an ideal world, what we want to do is say: don't interpolate if this variable is only used by resources that are being destroyed. But, I couldn't think of any clean way to do this.
This lead to plan B, which is this PR: don't evaluate any nodes that don't need to be evaluated. This is a depth-first optimization that asks every node: are you a noop? if it says yes, it removes it.
This PR makes two prun-able changes:
This fixes the bug and passes all other tests.
I'm fairly confident this won't introduce new bugs, but also confident that by tuning the prunes more carefully, we can probably also remove other bugs.