Fixes: #10581
When a cluster was originally created, you could not enable snapshotting
on it. An error message like this was found:
```
* aws_elasticache_replication_group.bar: Error updating Elasticache replication group: InvalidParameterCombination: Must specify both SnapshotRetentionLimit and SnapshottingClusterId to turn on snapshots
status code: 400, request id: 98d2ea4e-3fb1-11e7-b077-5967719aeab4
```
There is no guidance from AWS on which is the preferred Cluster in the RG to use for snapshotting. Therefore, I decided to set it to be the first cluster. We can now enable snapshotting
```
% make testacc TEST=./builtin/providers/aws/ TESTARGS='-run=TestAccAWSElasticacheReplicationGroup_enableSnapshotting'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/23 15:02:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws/ -v -run=TestAccAWSElasticacheReplicationGroup_enableSnapshotting -timeout 120m
=== RUN TestAccAWSElasticacheReplicationGroup_enableSnapshotting
--- PASS: TestAccAWSElasticacheReplicationGroup_enableSnapshotting (1261.47s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 1261.496s
```
During an instance shut-down network interfaces may be detached during the `READ` method of a Terraform run.
This protects the case where a network interface was detached, and is now `nil` at the time of the Terraform run, fixing nil pointer dereferences.
Previously lightsail was limited to `us-east-1` only. This restriction has now been lifted to new regions.
```
$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSLightsailInstance_euRegion'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/19 16:40:48 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSLightsailInstance_euRegion -timeout 120m
=== RUN TestAccAWSLightsailInstance_euRegion
--- PASS: TestAccAWSLightsailInstance_euRegion (45.31s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 45.319s
```
Fixes: #14668
The previous JSON validator that we were using for IAM policy documents wouldn't catch AWS IAM Policy errors.
The supplied policy document would pass our validator, then fail with the following API error:
```
* aws_iam_role_policy.foo: Error putting IAM role policy tf_test_policy_ymw7hbil9w: MalformedPolicyDocument: The policy failed legacy parsing
status code: 400, request id: e7615d90-3c99-11e7-babc-c14e741605bf
```
This happens if the Policy Document doesn't start with the opening JSON bracket, and often happens in the following case:
```
policy = <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
...
}
]
}
EOF
```
Where, when using a HEREDOC, the policy document is indented incorrectly.
The new validation function for the IAM policies verifies that the first character of the supplied policy document is the leading JSON bracket, prior to validating the JSON string.
Test Output:
```
$ make test TEST=./builtin/providers/aws/ TESTARGS="-v -run=TestValidateIAMPolicyJsonString"
==> Checking that code complies with gofmt requirements...
==> Checking AWS provider for unchecked errors...
==> NOTE: at this time we only look for uncheck errors in the AWS package
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/19 10:56:32 Generated command/internal_plugin_list.go
go test -i ./builtin/providers/aws/ || exit 1
echo ./builtin/providers/aws/ | \
xargs -t -n4 go test -v -run=TestValidateIAMPolicyJsonString -timeout=60s -parallel=4
go test -v -run=TestValidateIAMPolicyJsonString -timeout=60s -parallel=4 ./builtin/providers/aws/
=== RUN TestValidateIAMPolicyJsonString
--- PASS: TestValidateIAMPolicyJsonString (0.00s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 0.009s
```
```
$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAWSPolicy_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/19 10:38:43 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAWSPolicy_ -timeout 120m
=== RUN TestAWSPolicy_namePrefix
--- PASS: TestAWSPolicy_namePrefix (20.01s)
=== RUN TestAWSPolicy_invalidJson
--- PASS: TestAWSPolicy_invalidJson (0.00s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 20.027s
```
```
$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSIAMRolePolicy_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/19 11:02:56 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSIAMRolePolicy_ -timeout 120m
=== RUN TestAccAWSIAMRolePolicy_importBasic
--- PASS: TestAccAWSIAMRolePolicy_importBasic (18.45s)
=== RUN TestAccAWSIAMRolePolicy_basic
--- PASS: TestAccAWSIAMRolePolicy_basic (35.92s)
=== RUN TestAccAWSIAMRolePolicy_namePrefix
--- PASS: TestAccAWSIAMRolePolicy_namePrefix (14.78s)
=== RUN TestAccAWSIAMRolePolicy_generatedName
--- PASS: TestAccAWSIAMRolePolicy_generatedName (20.20s)
=== RUN TestAccAWSIAMRolePolicy_invalidJSON
--- PASS: TestAccAWSIAMRolePolicy_invalidJSON (0.00s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 89.363s
```
Fixes: #14653
I was originally calling the wrong API method and only some of the
values were being persisted to state. By changing the API method, we can
now get all of the values and therefore can detech manual drift
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSSMMaintenanceWindow_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/19 16:56:27 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSSMMaintenanceWindow_ -timeout 120m
=== RUN TestAccAWSSSMMaintenanceWindow_basic
--- PASS: TestAccAWSSSMMaintenanceWindow_basic (41.39s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 41.419s
```
Fixes: #14535
When in a `restricted` cloud, we should fall back to the old method of
tagging. Before this change we saw the following:
```
% terraform apply ✭
aws_instance.foo: Creating...
ami: "" => "ami-0fa3c42c"
associate_public_ip_address: "" => "<computed>"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_state: "" => "<computed>"
instance_type: "" => "m1.small"
ipv6_address_count: "" => "<computed>"
ipv6_addresses.#: "" => "<computed>"
key_name: "" => "<computed>"
network_interface.#: "" => "<computed>"
network_interface_id: "" => "<computed>"
placement_group: "" => "<computed>"
primary_network_interface_id: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "true"
subnet_id: "" => "<computed>"
tags.%: "" => "1"
tags.foo: "" => "bar"
tenancy: "" => "<computed>"
volume_tags.%: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-0009f227ae24791b9)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
% terraform plan ✭
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
aws_instance.foo: Refreshing state... (ID: i-0009f227ae24791b9)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.
Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.
~ aws_instance.foo
tags.%: "0" => "1"
tags.foo: "" => "bar"
Plan: 0 to add, 1 to change, 0 to destroy.
```
After this patch, we see the following:
```
% terraform apply ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-provider.
If you did not expect to see this message you will need to remove the old plugin.
See https://www.terraform.io/docs/internals/internal-plugins.html
aws_instance.foo: Creating...
ami: "" => "ami-0fa3c42c"
associate_public_ip_address: "" => "<computed>"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_state: "" => "<computed>"
instance_type: "" => "m1.small"
ipv6_address_count: "" => "<computed>"
ipv6_addresses.#: "" => "<computed>"
key_name: "" => "<computed>"
network_interface.#: "" => "<computed>"
network_interface_id: "" => "<computed>"
placement_group: "" => "<computed>"
primary_network_interface_id: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "true"
subnet_id: "" => "<computed>"
tags.%: "" => "1"
tags.foo: "" => "bar"
tenancy: "" => "<computed>"
volume_tags.%: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-04cd122e28f167a14)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
% terraform plan ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-provider.
If you did not expect to see this message you will need to remove the old plugin.
See https://www.terraform.io/docs/internals/internal-plugins.html
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
aws_instance.foo: Refreshing state... (ID: i-04cd122e28f167a14)
No changes. Infrastructure is up-to-date.
This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```
Fixes: #14530
When we found an update of IPv6 cidr block, we first tried to
disassociate the old cidr block association. This caused errors if there
was none, it threw an error, as we passed an empty associationId:
```
* aws_subnet.public_subnet.0: InvalidSubnetCidrBlockAssociationId.Malformed: The subnet CIDR block with association ID is malformed
status code: 400, request id: f438f468-9ca4-4000-ba78-63a0f25d390a
* aws_subnet.public_subnet[1]: 1 error(s) occurred:
```
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSubnet_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/16 18:28:45 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSubnet_ -timeout 120m
=== RUN TestAccAWSSubnet_importBasic
--- PASS: TestAccAWSSubnet_importBasic (55.40s)
=== RUN TestAccAWSSubnet_basic
--- PASS: TestAccAWSSubnet_basic (53.62s)
=== RUN TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (125.87s)
=== RUN TestAccAWSSubnet_enableIpv6
--- PASS: TestAccAWSSubnet_enableIpv6 (88.88s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 323.787s
```
Fixes: #14361
An IPv6 CIDR block is option and can be added *after* a subnet has been
created. Therefore, we should set it to `Computed: true`
Otherwise, a manually created IPv6 association will be removed on the
next terraform run
* Propagate AWS CodePipeline action roles
* Add acceptance test for AWS CodePipeline action roles
* Isolate AWS CodePipeline service role acceptance test
Paul Stack