* Propagate AWS CodePipeline action roles
* Add acceptance test for AWS CodePipeline action roles
* Isolate AWS CodePipeline service role acceptance test
The existing "tag" field on autoscaling groups is very limited in that it
cannot be used in conjunction with interpolation preventing from adding
dynamic tag entries.
Other AWS resources don't have this restriction on tags because they work
directly on the map type.
AWS autoscaling groups on the other hand have an additional field
"propagate_at_launch" which is not usable with a pure map type.
This fixes it by introducing an additional field called "tags" which
allows specifying a list of maps. This preserves the possibility to
declare tags as with the "tag" field but additionally allows to
construct lists of maps using interpolation syntax.
Fixes: #14503
Changes to root_block_device were not picked up as we had a hash func to
return 0. We changed from set -> list as we only allow 1 value and
immediately we can get changes propagating
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSLaunchConfiguration_updateRootBlockDevice'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/15 19:27:39 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSLaunchConfiguration_updateRootBlockDevice -timeout 120m
=== RUN TestAccAWSLaunchConfiguration_updateRootBlockDevice
--- PASS: TestAccAWSLaunchConfiguration_updateRootBlockDevice (51.12s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 51.140s
```
Fixes: #14006Fixes: #14464
IPv6 wasn't supported for adding routes to the internet gateway.
Resulted in a message as follows:
```
Error creating route: MissingParameter: The request must contain the parameter destinationCidrBlock or destinationIpv6CidrBlock
```
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSRoute_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/15 11:50:43 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSRoute_ -timeout 120m
=== RUN TestAccAWSRoute_basic
--- PASS: TestAccAWSRoute_basic (67.27s)
=== RUN TestAccAWSRoute_ipv6Support
--- PASS: TestAccAWSRoute_ipv6Support (59.35s)
=== RUN TestAccAWSRoute_ipv6ToInternetGateway
--- PASS: TestAccAWSRoute_ipv6ToInternetGateway (67.39s)
=== RUN TestAccAWSRoute_changeCidr
--- PASS: TestAccAWSRoute_changeCidr (103.68s)
=== RUN TestAccAWSRoute_noopdiff
--- PASS: TestAccAWSRoute_noopdiff (194.32s)
=== RUN TestAccAWSRoute_doesNotCrashWithVPCEndpoint
--- PASS: TestAccAWSRoute_doesNotCrashWithVPCEndpoint (71.36s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 563.397s
```
The acceptance tests for spot_instance_requests were showing falures as
follows:
```
------- Stdout: -------
=== RUN TestAccAWSSpotInstanceRequest_basic
--- FAIL: TestAccAWSSpotInstanceRequest_basic (100.40s)
testing.go:280: Step 0 error: After applying this step, the plan was not empty:
DIFF:
UPDATE: aws_spot_instance_request.foo
volume_tags.%: "" => "<computed>"
```
This was because we were setting volume_tags as computed and thus the
diff. We needed to override the schema to make sure that it was not
being computed - it's only aws_instance that needs computed tags because
of EBS volumes
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSpotInstanceRequest_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/15 10:41:36 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSpotInstanceRequest_ -timeout 120m
=== RUN TestAccAWSSpotInstanceRequest_basic
--- PASS: TestAccAWSSpotInstanceRequest_basic (86.93s)
=== RUN TestAccAWSSpotInstanceRequest_withBlockDuration
--- PASS: TestAccAWSSpotInstanceRequest_withBlockDuration (97.47s)
=== RUN TestAccAWSSpotInstanceRequest_vpc
--- PASS: TestAccAWSSpotInstanceRequest_vpc (234.56s)
=== RUN TestAccAWSSpotInstanceRequest_SubnetAndSG
--- PASS: TestAccAWSSpotInstanceRequest_SubnetAndSG (146.16s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 565.131s
```
Fixes: #14032
When you are using an IPv6 address directly to an instance, it was
causing the ipv6_address_count to try and ForceNew resource. It wasn't
marked as computed
I was able to see this here:
```
-/+ aws_instance.test
ami: "ami-c5eabbf5" => "ami-c5eabbf5"
associate_public_ip_address: "false" => "<computed>"
availability_zone: "us-west-2a" => "<computed>"
ebs_block_device.#: "0" => "<computed>"
ephemeral_block_device.#: "0" => "<computed>"
instance_state: "running" => "<computed>"
instance_type: "t2.micro" => "t2.micro"
ipv6_address_count: "1" => "0" (forces new resource)
ipv6_addresses.#: "1" => "1"
ipv6_addresses.0: "2600:1f14:bb2:e501::10" => "2600:1f14:bb2:e501::10"
key_name: "" => "<computed>"
network_interface.#: "0" => "<computed>"
network_interface_id: "eni-d19115ec" => "<computed>"
placement_group: "" => "<computed>"
primary_network_interface_id: "eni-d19115ec" => "<computed>"
private_dns: "ip-10-20-1-252.us-west-2.compute.internal" => "<computed>"
private_ip: "10.20.1.252" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "1" => "<computed>"
security_groups.#: "0" => "<computed>"
source_dest_check: "true" => "true"
subnet_id: "subnet-3fdfb476" => "subnet-3fdfb476"
tags.%: "1" => "1"
tags.Name: "stack72" => "stack72"
tenancy: "default" => "<computed>"
volume_tags.%: "0" => "<computed>"
vpc_security_group_ids.#: "1" => "<computed>"
```
It now works as expected:
```
% 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_vpc.foo: Refreshing state... (ID: vpc-fa61669d)
aws_subnet.foo: Refreshing state... (ID: subnet-3fdfb476)
aws_internet_gateway.foo: Refreshing state... (ID: igw-70629a17)
aws_route_table.test: Refreshing state... (ID: rtb-0a52e16c)
aws_instance.test: Refreshing state... (ID: i-0971755345296aca5)
aws_route_table_association.a: Refreshing state... (ID: rtbassoc-b12493c8)
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.
```
We should error check up front on the use of num_cache_nodes and
cluster_mode. This allows us to write a test to make sure all works as
expected
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSElasticacheReplicationGroup_clusteringAndCacheNodesCausesError'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/09 19:04:56 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSElasticacheReplicationGroup_clusteringAndCacheNodesCausesError -timeout 120m
=== RUN TestAccAWSElasticacheReplicationGroup_clusteringAndCacheNodesCausesError
--- PASS: TestAccAWSElasticacheReplicationGroup_clusteringAndCacheNodesCausesError (40.58s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 40.603s
```
Added support for provisioning a native redis cluster elasticache replication group.
A new TypeSet attribute `cluster_mode` has been added. It requires the following
fields:
- `replicas_per_node_group` - The number of replica nodes in each node group
- `num_node_groups` - The number of node groups for this Redis replication group
Notes:
- `automatic_failover_enabled` must be set to true.
- `number_cache_clusters` is now a optional and computed field. If `cluster_mode` is set
its value will be computed as:
```num_node_groups + num_node_groups * replicas_per_node_group```
Below is a sample config:
resource "aws_elasticache_replication_group" "bar" {
replication_group_id = "tf-redis-cluser"
replication_group_description = "test description"
node_type = "cache.t2.micro"
port = 6379
parameter_group_name = "default.redis3.2.cluster.on"
automatic_failover_enabled = true
cluster_mode {
replicas_per_node_group = 1
num_node_groups = 2
}
}
We were too greedy with the AWS specific tags ignore function - we
basically were ignoring anything starting with `aws` rather than just
using `aws:`
Fixes: #14308Fixes: #14247
Christopher Elkins