do not connect destroy and resource nodes

Destroy nodes do not need to be connected to the resource (prepare
state) node when adding them to the graph. Destroy nodes already have a
complete state in the graph (which is being destroyed), any references
will be added in the ReferenceTransformer, and the proper
connection to the create node will be added in the
DestroyEdgeTransformer.

Under normal circumstances this makes no difference, as create and
destroy nodes always have an dependency, so having the prepare state
handled before both only linearizes the operation slightly in the
normal destroy-then-create scenario.

However if there is a dependency on a resource being replaced in another
module, there will be a dependency between the destroy nodes in each
module (to complete the destroy ordering), while the resource node will
depend on the variable->output->resource chain. If both the destroy and
create nodes depend on the resource node, there will be a cycle.
This commit is contained in:
James Bardin 2019-09-27 21:47:03 -04:00
parent 3eb0e74ef9
commit eb6e7bba2e
2 changed files with 2 additions and 9 deletions

View File

@ -522,8 +522,9 @@ root
test_object.A (prepare state)
provider.test
test_object.A[1] (destroy)
test_object.A (prepare state)
provider.test
test_object.B
test_object.A (prepare state)
test_object.A[1] (destroy)
test_object.B (prepare state)
test_object.B (prepare state)

View File

@ -174,14 +174,6 @@ func (t *DiffTransformer) Transform(g *Graph) error {
log.Printf("[TRACE] DiffTransformer: %s deposed object %s will be represented for destruction by %s", addr, dk, dag.VertexName(node))
}
g.Add(node)
rsrcAddr := addr.ContainingResource().String()
for _, rsrcNode := range resourceNodes[rsrcAddr] {
// We connect this edge "forwards" (even though destroy dependencies
// are often inverted) because evaluating the resource node
// after the destroy node could cause an unnecessary husk of
// a resource state to be re-added.
g.Connect(dag.BasicEdge(node, rsrcNode))
}
}
}