The `CloseProviderTransformer` relies on the `ProvidedBy()` interface to
look up the proper dependency for the the graph nodes it adds. This
interface needs to yield the name of a provider, _AND_ for flattened
nodes it needs to yield the full path to a provider.
Destroy nodes did not implement this second part, which resulted in
"provider X couldn't be found" when both of these were true:
* A module included a resource that dependend on a provider
* The root did _NOT_ include a provider config
Implementing a proper ProvidedBy() on the flattened version of
destroy nodes solves the issue.
fixes#2581
fixes#1947
Root cause was a bad edge being made by the CBD transform going from the
flattened destroy node to the unflattened create node, which was no
longer in the graph. The destroy node therefore had a dependency that
could never be satisfied, which locked up the walk.
Adds the ability to target resources within modules, like:
module.mymod.aws_instance.foo
And the ability to target all resources inside a module, like:
module.mymod
Closes#1434
This reimplements my prior attempt at nipping issues where a plan did
not yield the same cycle an apply did. My prior attempt was to have
ctx.Validate generate a "Verbose" worst-case graph. It turns out that
skipping PruneDestroyTransformer to generate this graph misses important
heuristics that prevent cycles by dropping destroy nodes that are
determined to be unused.
This resulted in Validate improperly failing in scenarios where these
heuristics would have broken the cycle.
We detected the problem during the work on #1781 and worked around the
issue by reverting to the non-Verbose graph in Validate.
This commit accomplishes the original goal in a better way - by
generating the full graph and checking it once Plan has calculated the
diff. This guarantees that any graph issue that would be caught by Apply
will be caught by Plan.
