* Attempt to write a new test for cert update
Trying to surface this bug with a test:
https://github.com/hashicorp/terraform/issues/5930
* Fix the error
* Fix the test for the update operation
* Break apart tests for EU vs US to cleanse test run
* Refactor Update to more closely match create, increase debug logging
* Reflect differences of EU and US regions via separate tests
* Add comment re: why of test breakout
* Removed the “SetId” as it was unnecessary
* Ensure the SSL Addon has been provisioned
* Add resource
* Add tests
* Add documentation
* Fix invalid comment
* Remove MinItems
* Add newline
* Store expected ID and format
* Add import note
* expiration_time can be computed if dataset has an expiration_time set
* Handle 404 using new check function
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
Chris Johnson