The original contents of `vendor` were inadvertently captured with an
older version of `godep`. Here, we recapture dependencies by running the
following:
```
godep restore -v
cat Godeps/Godeps.json | jq -r '.Deps[].ImportPath' | xargs godep update -v
```
The newer godep makes the following changes as it captures dependencies:
* Skips test files
* Copies `LICENSE` / `PATENTS` files
There is also an additional diff in `golang.org/x/sys/unix` that looks
very similar to the diff between `master..c65f27f` in that repo, so I'm
guessing that dependency was accidentally captured from master instead
of the commit saved to `Godeps.json`.
All in all, these changes should all be "more correct" and result in
smaller diffs for any future updates made to dependencies.
Fixes issue #4985 by correcting copy/paste error that caused the
max_utilization attribute to be read from the max_rate_per_instance
attribute.
N.B. There is still no test coverage for this issue.
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)
Radek Simko