Previously, any old HTTP error would be treated as the security_group_rule being
deleted. In reality there are only a few cases where this is the right
assumption.
This workaround is originally from 71b30c633f.
According to the commit message from Mitchell Hashimoto:
So I think the AWS API is just broken here. In the case that the state
doesn't update, just assume it did after 5 seconds.
Based on my experience, this AWS API is still broken in the same way.
The timeout was later increased from 5 seconds to 10 seconds in
265cc4fffa.
The timeout (but not the timer) was removed inexplicably in GH-1325.
The symptom is this error from `terraform apply`:
aws_internet_gateway.test: Error waiting for internet gateway (igw-553b4731) to attach: timeout while waiting for state to become '[available]'
followed by all subsequent `terraform apply` commands failing with this error:
aws_internet_gateway.test: Resource.AlreadyAssociated: resource igw-553b4731 is already attached to network vpc-61bc7606
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSESReceiptFilter_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSSESReceiptFilter_ -timeout 120m
=== RUN TestAccAWSSESReceiptFilter_importBasic
--- PASS: TestAccAWSSESReceiptFilter_importBasic (18.18s)
=== RUN TestAccAWSSESReceiptFilter_basic
--- PASS: TestAccAWSSESReceiptFilter_basic (18.42s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 36.633s
```
```
make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSESReceiptRuleSet_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSSESReceiptRuleSet_ -timeout 120m
=== RUN TestAccAWSSESReceiptRuleSet_importBasic
--- PASS: TestAccAWSSESReceiptRuleSet_importBasic (18.60s)
=== RUN TestAccAWSSESReceiptRuleSet_basic
--- PASS: TestAccAWSSESReceiptRuleSet_basic (26.92s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 45.550s
```
JUst needed some rejigging of the skip_final_snapshot work as that isn't
returned by the API and skipping it means the destroy fails due to
missing final_snapshot_identifier
```
% make testacc TEST=./builtin/providers/aws
% TESTARGS='-run=TestAccAWSDBInstance_' ✹ ✭
==> Checking that code complies with gofmt requirements...
/Users/stacko/Code/go/bin/stringer
go generate $(go list ./... | grep -v /vendor/)
2016/07/07 15:28:31 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSDBInstance_
-timeout 120m
=== RUN TestAccAWSDBInstance_importBasic
--- PASS: TestAccAWSDBInstance_importBasic (588.70s)
=== RUN TestAccAWSDBInstance_basic
--- PASS: TestAccAWSDBInstance_basic (595.71s)
=== RUN TestAccAWSDBInstance_kmsKey
--- PASS: TestAccAWSDBInstance_kmsKey (726.46s)
=== RUN TestAccAWSDBInstance_optionGroup
--- PASS: TestAccAWSDBInstance_optionGroup (681.78s)
=== RUN TestAccAWSDBInstance_iops_update
--- PASS: TestAccAWSDBInstance_iops_update
(590.81s)
```
Please note that I cannot run the enhanced monitoring test in my
environment as I have already got it attached to an IAM role. Running
that test gives me this result:
```
```
* Fix nested module "unknown variable" during dstry
During a destroy with nested modules, accessing a variable between them
causes an "unknown variable accessed" during destroy.
In scenarios with a lot of small configs, it's tedious to fan out actual
dir trees in a test-fixtures dir. It also spreads out the context of the
test - requiring the reader fetch a bunch of scattered 3 line files in
order to understand what is being tested.
Our config loading code still only reads from disk, but in
the `helper/resource` acc test framework we work around this by writing
inline config to temp files and loading it from there. This helper is
based on that strategy.
Eventually it'd be great to be able to build up a `module.Tree` from
config directly, but this gets us the functionality today.
Example Usage:
testModuleInline(t, map[string]string{
"top.tf": `
module "middle" {
source = "./middle"
}
`,
"middle/mid.tf": `
module "bottom" {
source = "./bottom"
amap {
foo = "bar"
}
}
`,
"middle/bottom/bot.tf": `
variable "amap" {
type = "map"
}
`,
}),
The symptom is that a route "fails" to create, then every subsequent
`terraform apply` fails with RouteAlreadyExists.
CreateRoute was succeeding but the very next DescribeRouteTables
was not listing the new route.
This fixes#7157. It doesn't change the way aws_ami works
```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSAMICopy'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSAMICopy
-timeout 120m
=== RUN TestAccAWSAMICopy
--- PASS: TestAccAWSAMICopy (479.75s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 479.769s
```
Fixes#7433
When an EFS File System is created via Terraform, Deleted from the AWS
console, then Terraform would give us as error as:
```
* aws_efs_file_system.file_system: FileSystemNotFound: File system
'fs-9d739e54' does not exist.
status code: 404, request id:
d505a682-3ec7-11e6-81d3-1d41202f0881
```
On a 404, we now remove the EFS File System from state so that Terraform
can recreate it as expected
Guarding against `invalid memory address` in AdditionalUnattendConfig
```
make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_windowsUnattendedConfig'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_windowsUnattendedConfig -timeout 120m
=== RUN TestAccAzureRMVirtualMachine_windowsUnattendedConfig
--- PASS: TestAccAzureRMVirtualMachine_windowsUnattendedConfig (943.28s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm
943.299s
```
James Nugent