* Randomize app name in test
* Return error and don't panic when there is a problem
It's possible there may still be an underlying problem that caused the
error that made the cert leak in the first place - this should help us
diagnose it.
This should address the failures seen in Travis Build Run #8774. It is
likely there are others which also need addressing - they will be
addressed on a case-by-case basis as they come up.
This is a follow up on #4892 with tests that demonstrate creating a record and a zone, then destroying said record, and confirming that a new plan is generated, using the ExpectNonEmptyPlan flag
This simulates the bug reported in #4641 by mimicking the state file that one would have if they created a record with Terraform v0.6.6, which is to say a weight = 0 for a default value.
When upgrading, there would be an expected plan change to get that to -1. To mimic the statefile we apply the record and then in a follow up step change the attributes directly. We then try to delete the record.
I tested this by grabbing the source of aws_resource_route53.go from Terraform v0.6.9 and running the included test, which fails. The test will pass with #4892 , because we no longer reconstruct what the record should be based on the state (instead finding via the API and elimination/matching)
This resource is the first which makes use of the new Riviera library
(at https://github.com/jen20/riviera), so there is some additional set
up work to add the provider to the client which gets passed among
resources.
Previous deps merge had been captured by an older version of godep,
updating godep and rerunning...
godep save $(go list ./... | grep -v /vendor/)
...yielded this diff.
New `godep` also produced a warning to pin to the major Go version
instead of the minor one, which we do here as well.
Doing a straight `./...` build results in errors from unvendored
package references being picked up in some vendored libraries'
`examples/` subdirs.
So we'll switch to the recommended `go list | grep -v /vendor/` strategy
to determine what to build.
This commit adds the ability to associate a Floating IP to a specific
network. Previously, there only existed a top-level floating IP
attribute which was automatically associated with either the first
defined network or the default network (when no network block was
used).
Now floating IPs can be associated with networks beyond the first
defined network as well as each network being able to have their own
floating IP.
Specifying the floating IP by using the top-level floating_ip
attribute and the per-network floating IP attribute is not possible.
Additionally, an `access_network` attribute has been added in order
to easily specify which network should be used for provisioning.
Paul Hinze