Context:
As part of building up a Plan, Terraform needs to detect "orphaned"
resources--resources which are present in the state but not in the
config. This happens when config for those resources is removed by the
user, making it Terraform's responsibility to destroy them.
Both state and config are organized by Module into a logical tree, so
the process of finding orphans involves checking for orphaned Resources
in the current module and for orphaned Modules, which themselves will
have all their Resources marked as orphans.
Bug:
In #3114 a problem was exposed where, given a module tree that looked
like this:
```
root
|
+-- parent (empty, except for sub-modules)
|
+-- child1 (1 resource)
|
+-- child2 (1 resource)
```
If `parent` was removed, a bunch of error messages would occur during
the plan. The root cause of this was duplicate orphans appearing for the
resources in child1 and child2.
Fix:
This turned out to be a bug in orphaned module detection. When looking
for deeply nested orphaned modules, root.parent was getting added twice
as an orphaned module to the graph.
Here, we add an additional check to prevent a double add, which
addresses this scenario properly.
Fixes#3114 (the Provisioner side of it was fixed in #4877)
Fixes an interpolation race that was occurring when a tainted destroy
node and a primary destroy node both tried to interpolate a computed
count in their config. Since they were sharing a pointer to the _same_
config, depending on how the race played out one of them could catch the
config uninterpolated and would then throw a syntax error.
The `Copy()` tree implemented for this fix can probably be used
elsewhere - basically we should copy the config whenever we drop nodes
into the graph - but for now I'm just applying it to the place that
fixes this bug.
Fixes#4982 - Includes a test covering that race condition.
The AWS free tier allows up to 750 hours on t2.micro
instance types. It's better to use cheaper instances
in case the resources are not cleaned up if a tests
is canceled or crashes.
There can only be a single health_check configuration per load balancer
so choosing to use a list over a set is only relevant when comparing
changes during a plan. A list makes it much easier to compare updates
since the index is stable (0 vs. computed hash).
Removes overspecified config that is unrelated to testing the auto scaling
group's autogenerated name. The test is only concerned with checking that
the auto scaling group was created successfully with an autogenerated name
matching a specific pattern.
Removes overspecified config that is unrelated to the auto scaling
group's availability zone and VPC identifier acceptance tests. The
created auto scaling groups do not need to spin up any hosts since
the acceptance tests are only concerned with checking the existence
of the associated availability zones and VPC identifiers.
Fixes a diff calculation error when only a VPC zone
identifiers is provided. In this case the associated
availability zones are computed from the subnets per
the AWS documentation.
Paul Hinze