opentofu/terraform/transform_targets.go

262 lines
8.2 KiB
Go
Raw Normal View History

package terraform
import (
"log"
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
"github.com/hashicorp/terraform/addrs"
"github.com/hashicorp/terraform/dag"
)
// GraphNodeTargetable is an interface for graph nodes to implement when they
// need to be told about incoming targets. This is useful for nodes that need
// to respect targets as they dynamically expand. Note that the list of targets
// provided will contain every target provided, and each implementing graph
// node must filter this list to targets considered relevant.
type GraphNodeTargetable interface {
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
SetTargets([]addrs.Targetable)
}
core: Allow downstream targeting of certain node types The previous behavior of targets was that targeting a particular node would implicitly target everything it depends on. This makes sense when the dependencies in question are between resources, since we need to make sure all of a resource's dependencies are in place before we can create or update it. However, it had the undesirable side-effect that targeting a resource would _exclude_ any outputs referring to it, since the dependency edge goes from output to resource. This then causes the output to be "stale", which is problematic when outputs are being consumed by downstream configs using terraform_remote_state. GraphNodeTargetDownstream allows nodes to opt-in to a new behavior where they can be targeted by _inverted_ dependency edges. That is, it allows outputs to be considered targeted if anything they directly depend on is targeted. This is different than the implied targeting behavior in the other direction because transitive dependencies are not considered unless the intermediate nodes themselves have TargetDownstream. This means that an output1→output2→resource chain can implicitly target both outputs, but an output→resource1→resource2 chain _won't_ target the output if only resource2 is targeted. This behavior creates a scenario where an output can be visited before all of its dependencies are ready, since it may have a mixture of both targeted and untargeted dependencies. This is fine for outputs because they silently ignore any errors encountered during interpolation anyway, but other hypothetical future implementers of this interface may need to be more careful. This fixes #14186.
2017-05-10 20:27:49 -05:00
// GraphNodeTargetDownstream is an interface for graph nodes that need to
// be remain present under targeting if any of their dependencies are targeted.
// TargetDownstream is called with the set of vertices that are direct
// dependencies for the node, and it should return true if the node must remain
// in the graph in support of those dependencies.
//
// This is used in situations where the dependency edges are representing an
// ordering relationship but the dependency must still be visited if its
// dependencies are visited. This is true for outputs, for example, since
// they must get updated if any of their dependent resources get updated,
// which would not normally be true if one of their dependencies were targeted.
type GraphNodeTargetDownstream interface {
TargetDownstream(targeted, untargeted *dag.Set) bool
}
// TargetsTransformer is a GraphTransformer that, when the user specifies a
// list of resources to target, limits the graph to only those resources and
// their dependencies.
type TargetsTransformer struct {
// List of targeted resource names specified by the user
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
Targets []addrs.Targetable
core: -target option to also select resources in descendant modules 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.
2017-06-15 20:15:41 -05:00
// If set, the index portions of resource addresses will be ignored
// for comparison. This is used when transforming a graph where
// counted resources have not yet been expanded, since otherwise
// the unexpanded nodes (which never have indices) would not match.
IgnoreIndices bool
// Set to true when we're in a `terraform destroy` or a
// `terraform plan -destroy`
Destroy bool
}
func (t *TargetsTransformer) Transform(g *Graph) error {
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
if len(t.Targets) > 0 {
targetedNodes, err := t.selectTargetedNodes(g, t.Targets)
if err != nil {
return err
}
for _, v := range g.Vertices() {
removable := false
if _, ok := v.(GraphNodeResource); ok {
removable = true
}
if vr, ok := v.(RemovableIfNotTargeted); ok {
removable = vr.RemoveIfNotTargeted()
}
if removable && !targetedNodes.Include(v) {
log.Printf("[DEBUG] Removing %q, filtered by targeting.", dag.VertexName(v))
g.Remove(v)
}
}
}
return nil
}
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
// Returns a set of targeted nodes. A targeted node is either addressed
// directly, address indirectly via its container, or it's a dependency of a
// targeted node. Destroy mode keeps dependents instead of dependencies.
func (t *TargetsTransformer) selectTargetedNodes(g *Graph, addrs []addrs.Targetable) (*dag.Set, error) {
targetedNodes := new(dag.Set)
core: Allow downstream targeting of certain node types The previous behavior of targets was that targeting a particular node would implicitly target everything it depends on. This makes sense when the dependencies in question are between resources, since we need to make sure all of a resource's dependencies are in place before we can create or update it. However, it had the undesirable side-effect that targeting a resource would _exclude_ any outputs referring to it, since the dependency edge goes from output to resource. This then causes the output to be "stale", which is problematic when outputs are being consumed by downstream configs using terraform_remote_state. GraphNodeTargetDownstream allows nodes to opt-in to a new behavior where they can be targeted by _inverted_ dependency edges. That is, it allows outputs to be considered targeted if anything they directly depend on is targeted. This is different than the implied targeting behavior in the other direction because transitive dependencies are not considered unless the intermediate nodes themselves have TargetDownstream. This means that an output1→output2→resource chain can implicitly target both outputs, but an output→resource1→resource2 chain _won't_ target the output if only resource2 is targeted. This behavior creates a scenario where an output can be visited before all of its dependencies are ready, since it may have a mixture of both targeted and untargeted dependencies. This is fine for outputs because they silently ignore any errors encountered during interpolation anyway, but other hypothetical future implementers of this interface may need to be more careful. This fixes #14186.
2017-05-10 20:27:49 -05:00
vertices := g.Vertices()
for _, v := range vertices {
if t.nodeIsTarget(v, addrs) {
targetedNodes.Add(v)
// We inform nodes that ask about the list of targets - helps for nodes
// that need to dynamically expand. Note that this only occurs for nodes
// that are already directly targeted.
if tn, ok := v.(GraphNodeTargetable); ok {
tn.SetTargets(addrs)
}
var deps *dag.Set
var err error
if t.Destroy {
deps, err = g.Descendents(v)
} else {
deps, err = g.Ancestors(v)
}
if err != nil {
return nil, err
}
for _, d := range deps.List() {
targetedNodes.Add(d)
}
}
}
return t.addDependencies(targetedNodes, g)
}
func (t *TargetsTransformer) addDependencies(targetedNodes *dag.Set, g *Graph) (*dag.Set, error) {
core: Allow downstream targeting of certain node types The previous behavior of targets was that targeting a particular node would implicitly target everything it depends on. This makes sense when the dependencies in question are between resources, since we need to make sure all of a resource's dependencies are in place before we can create or update it. However, it had the undesirable side-effect that targeting a resource would _exclude_ any outputs referring to it, since the dependency edge goes from output to resource. This then causes the output to be "stale", which is problematic when outputs are being consumed by downstream configs using terraform_remote_state. GraphNodeTargetDownstream allows nodes to opt-in to a new behavior where they can be targeted by _inverted_ dependency edges. That is, it allows outputs to be considered targeted if anything they directly depend on is targeted. This is different than the implied targeting behavior in the other direction because transitive dependencies are not considered unless the intermediate nodes themselves have TargetDownstream. This means that an output1→output2→resource chain can implicitly target both outputs, but an output→resource1→resource2 chain _won't_ target the output if only resource2 is targeted. This behavior creates a scenario where an output can be visited before all of its dependencies are ready, since it may have a mixture of both targeted and untargeted dependencies. This is fine for outputs because they silently ignore any errors encountered during interpolation anyway, but other hypothetical future implementers of this interface may need to be more careful. This fixes #14186.
2017-05-10 20:27:49 -05:00
// Handle nodes that need to be included if their dependencies are included.
// This requires multiple passes since we need to catch transitive
// dependencies if and only if they are via other nodes that also
// support TargetDownstream. For example:
// output -> output -> targeted-resource: both outputs need to be targeted
// output -> non-targeted-resource -> targeted-resource: output not targeted
//
// We'll keep looping until we stop targeting more nodes.
queue := targetedNodes.List()
for len(queue) > 0 {
vertices := queue
queue = nil // ready to append for next iteration if neccessary
for _, v := range vertices {
dependers := g.UpEdges(v)
if dependers == nil {
// indicates that there are no up edges for this node, so
// we have nothing to do here.
continue
}
dependers = dependers.Filter(func(dv interface{}) bool {
_, ok := dv.(GraphNodeTargetDownstream)
return ok
})
if dependers.Len() == 0 {
continue
}
for _, dv := range dependers.List() {
if targetedNodes.Include(dv) {
// Already present, so nothing to do
continue
}
// We'll give the node some information about what it's
// depending on in case that informs its decision about whether
// it is safe to be targeted.
deps := g.DownEdges(v)
core: Allow downstream targeting of certain node types The previous behavior of targets was that targeting a particular node would implicitly target everything it depends on. This makes sense when the dependencies in question are between resources, since we need to make sure all of a resource's dependencies are in place before we can create or update it. However, it had the undesirable side-effect that targeting a resource would _exclude_ any outputs referring to it, since the dependency edge goes from output to resource. This then causes the output to be "stale", which is problematic when outputs are being consumed by downstream configs using terraform_remote_state. GraphNodeTargetDownstream allows nodes to opt-in to a new behavior where they can be targeted by _inverted_ dependency edges. That is, it allows outputs to be considered targeted if anything they directly depend on is targeted. This is different than the implied targeting behavior in the other direction because transitive dependencies are not considered unless the intermediate nodes themselves have TargetDownstream. This means that an output1→output2→resource chain can implicitly target both outputs, but an output→resource1→resource2 chain _won't_ target the output if only resource2 is targeted. This behavior creates a scenario where an output can be visited before all of its dependencies are ready, since it may have a mixture of both targeted and untargeted dependencies. This is fine for outputs because they silently ignore any errors encountered during interpolation anyway, but other hypothetical future implementers of this interface may need to be more careful. This fixes #14186.
2017-05-10 20:27:49 -05:00
depsTargeted := deps.Intersection(targetedNodes)
depsUntargeted := deps.Difference(depsTargeted)
if dv.(GraphNodeTargetDownstream).TargetDownstream(depsTargeted, depsUntargeted) {
targetedNodes.Add(dv)
// Need to visit this node on the next pass to see if it
// has any transitive dependers.
queue = append(queue, dv)
}
}
}
}
return targetedNodes.Filter(func(dv interface{}) bool {
return filterPartialOutputs(dv, targetedNodes, g)
}), nil
}
// Outputs may have been included transitively, but if any of their
// dependencies have been pruned they won't be resolvable.
// If nothing depends on the output, and the output is missing any
// dependencies, remove it from the graph.
// This essentially maintains the previous behavior where interpolation in
// outputs would fail silently, but can now surface errors where the output
// is required.
func filterPartialOutputs(v interface{}, targetedNodes *dag.Set, g *Graph) bool {
// should this just be done with TargetDownstream?
if _, ok := v.(*NodeApplyableOutput); !ok {
return true
}
dependers := g.UpEdges(v)
for _, d := range dependers.List() {
if _, ok := d.(*NodeCountBoundary); ok {
continue
}
if !targetedNodes.Include(d) {
// this one is going to be removed, so it doesn't count
continue
}
// as soon as we see a real dependency, we mark this as
// non-removable
return true
}
depends := g.DownEdges(v)
for _, d := range depends.List() {
if !targetedNodes.Include(d) {
log.Printf("[WARN] %s missing targeted dependency %s, removing from the graph",
dag.VertexName(v), dag.VertexName(d))
return false
}
}
return true
}
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
func (t *TargetsTransformer) nodeIsTarget(v dag.Vertex, targets []addrs.Targetable) bool {
var vertexAddr addrs.Targetable
switch r := v.(type) {
case GraphNodeResourceInstance:
vertexAddr = r.ResourceInstanceAddr()
case GraphNodeResource:
vertexAddr = r.ResourceAddr()
default:
// Only resource and resource instance nodes can be targeted.
return false
}
_, ok := v.(GraphNodeResource)
if !ok {
return false
}
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
for _, targetAddr := range targets {
core: -target option to also select resources in descendant modules 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.
2017-06-15 20:15:41 -05:00
if t.IgnoreIndices {
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
// If we're ignoring indices then we'll convert any resource instance
// addresses into resource addresses. We don't need to convert
// vertexAddr because instance addresses are contained within
// their associated resources, and so .TargetContains will take
// care of this for us.
if instance, isInstance := targetAddr.(addrs.AbsResourceInstance); isInstance {
targetAddr = instance.ContainingResource()
}
core: -target option to also select resources in descendant modules 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.
2017-06-15 20:15:41 -05:00
}
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 12:33:53 -05:00
if targetAddr.TargetContains(vertexAddr) {
return true
}
}
return false
}
// RemovableIfNotTargeted is a special interface for graph nodes that
// aren't directly addressable, but need to be removed from the graph when they
// are not targeted. (Nodes that are not directly targeted end up in the set of
// targeted nodes because something that _is_ targeted depends on them.) The
// initial use case for this interface is GraphNodeConfigVariable, which was
// having trouble interpolating for module variables in targeted scenarios that
// filtered out the resource node being referenced.
type RemovableIfNotTargeted interface {
RemoveIfNotTargeted() bool
}