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.
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.
See the updated docs for more details and examples, but in short this
enables the `attributes` param from the Chef provisioner to accept a
raw JSON string.
Fixes#3074Fixes#3572
Using EnvDefaultFunc with a default of empty string causes the
validation which would ordinarily be performed by `Required: true` in
the schema to not have any effect. Instead validate the configuration
used to produce the ARM client before attempting to use it during
provider configuration.
throw an error:
* aws_sns_topic_subscription.checker: NotFound: Subscription does not
* exist
status code: 404, request id: b8ca0c27-1a62-57b3-8b96-43038a0ead86
Terraform wasn't refreshing the state when the topic gave a 404
This fix prevents tests incorrectly reporting dangling resources. It is
not sufficient to check just whether or not an error occurred when
iterating over the listed resources - checking the bool returned is also
required.
Remove the mime type validation since the part handler type allows for
custom types.
http://cloudinit.readthedocs.org/en/latest/topics/format.html#part-handler
The docs specify that if a part handler type is specified, one could use
custom mime types
Signed-off-by: Simon Thulbourn <simon+github@thulbourn.com>
It was a mistake to switched fully to `==` when activating waiting for
capacity on updates in #3947. Users that didn't set `min_elb_capacity ==
desired_capacity` and instead treated it as an actual "minimum" would
see timeouts for every create, since their target numbers would never be
reached exactly.
Here, we fix that regression by restoring the minimum waiting behavior
during creates.
In order to preserve all the stated behavior, I had to split out
different criteria for create and update, criteria which are now
exhaustively unit tested.
The set of fields that affect capacity waiting behavior has become a bit
of a mess. Next major release I'd like to rework all of these into a
more consistently named block of config. For now, just getting the
behavior correct and documented.
(Also removes all the fixed names from the ASG tests as I was hitting
collision issues running them over here.)
Fixes#4792
Implementation notes:
* The hash implementation was not considering key value, causing "diffs
did not match" errors when a value was updated. Switching to default
HashResource implementation fixes this
* Using HashResource as a default exposed a bug in helper/schema that
needed to be fixed so the Set function is picked up properly during
Read
* Stop writing back values into the `key` attribute; it triggers extra
diffs when `default` is used. Computed values all just go into `var`.
* Includes a state migration to prevent unnecessary diffs based on
"key" attribute hashcodes changing.
In the tests:
* Switch from leaning on the public demo Consul instance to requiring a
CONSUL_HTTP_ADDR variable be set pointing to a `consul agent -dev`
instance to be used only for testing.
* Add a test that exposes the updating issues and covers the fixes
Fixes#774Fixes#1866Fixes#3023
These resources use ARM to get keys for the storage API, but then use
the storage REST API as per the ASM provider. The code is significantly
reworked with better logging and error handling. The key functions can
be reused for queues and file storage resources when they get added.
Just some cosmetics and some cleaning up to make the code fit in a
little better with the existing code. Functionally no changes are made
and the existing tests still pass.
Test failures indicate that this operation doesn't always take effect
immediately:
https://travis-ci.org/hashicorp/terraform/builds/103764466
Add a simple poll to retry a few times until it does.
```
--- PASS: TestAccMailgunDomain_Basic (1.51s)
```
Verified that this does the trick by looping the test and watching the
logs for the retry behavior to kick in.
clint shryock