core: -target option to also select resources in descendant modules #15314
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
This is similar in purpose to Equals but it takes a hierarchical approach where modules contain their child modules, resources are contained by their modules, and indexed resource instances are contained by their resource names. Unlike "Equals", Contains is intended to be transitive, so if A contains B and B contains C, then C necessarily contains A. It is also directional: if A contains B then B does not also contain A unless A and B are identical. This results in more intuitive behavior for use-cases where the goal is to select a portion of the address space for an operation.
Previously the behavior for -target when given a module address was to target only resources directly within that module, ignoring any resources defined in child modules. This behavior turned out to be counter-intuitive, since users expected the -target address to be interpreted hierarchically. We'll now use the new "Contains" function for addresses, which provides a hierarchical "containment" concept that is more consistent with user expectations. In particular, it allows module.foo to match module.foo.module.bar.aws_instance.baz, where before that would not have been true. Since Contains isn't commutative (unlike Equals) this requires some special handling for targeting specific indices. When given an argument like -target=aws_instance.foo[0], the initial graph construction (for both plan and refresh) is for the resource nodes from configuration, which have not yet been expanded to separate indexed instances. Thus we need to do the first pass of TargetsTransformer in mode where indices are ignored, with the work then completed by the DynamicExpand method which re-applies the TargetsTransformer in index-sensitive mode. This is a breaking change for anyone depending on the previous behavior of -target, since it will now select more resources than before. There is no way provided to obtain the previous behavior. Eventually we may support negative targeting, which could then combine with positive targets to regain the previous behavior as an explicit choice.
jbardin
approved these changes
Jun 16, 2017
This was referenced Jul 19, 2017
|
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.
(This is adapted from #9236, originally submitted by @uhef. It is rebased and altered slightly in approach to be compatible with other changes that were made to
ResourceAddresssince the original PR was submitted.)Previously the behavior for
-targetwhen given a module address was to target only resources directly within that module, ignoring any resources defined in child modules.This behavior turned out to be counter-intuitive, since users expected the
-targetaddress to be interpreted hierarchically.We'll now use a new
Containsfunction for addresses, which provides a hierarchical "containment" concept that is more consistent with user expectations. In particular, it allowsmodule.footo matchmodule.foo.module.bar.aws_instance.baz, where before this would not have matched.Since
Containsisn't commutative (unlikeEquals) this requires some special handling for targeting specific resource indices. When given an argument like-target=aws_instance.foo[0], the initial graph construction (for both plan and refresh) is for the resource nodes from configuration, whichhave not yet been expanded to separate indexed instances. Thus we need to do the first pass of
TargetsTransformerin mode where indices are ignored, with the work then completed in theDynamicExpandmethod by re-applying theTargetsTransformerin index-sensitive mode within the dynamic subgraph.This is a breaking change for anyone depending on the previous behavior of
-target, since it will now select more resources than before. There is no way provided to obtain the previous behavior. Eventually we may support negative targeting, which could then combine with positive targets to regain the previous behavior as an explicit choice.This addresses #5190.
This change intended to land in 0.10 so we can properly announce the breaking change in targeting behavior as part of that release.