This covers the scenario of an instance created by a spot request. Using
Terraform we only know the spot request is fulfilled but the instance can
still be pending which causes the attachment to fail.
If an `aws_volume_attachment` is identical to one that already exists in
the API, don't attempt to re-create it (which fails), simply act as
though the creation command had already been run and continue.
This allows Terraform to cleanly recover from a situation where a volume
attachment action hangs indefinitely, possibly due to a bad instance
state, requiring manual intervention such as an instance reboot. In such
a situation, Terraform believes the attachment has failed, when in fact
it succeeded after the timeout had expired. On the subsequent retry run,
attempting to re-create the attachment will fail outright, due to the
AttachVolume API call being non-idempotent. This patch implements the
idempotency client-side by matching the (name, vID, iID) tuple.
Note that volume attachments are not assigned an ID by the API.
* provider/aws: Provide the option to skip_destroy on
aws_volume_attachment
When you want to attach and detach pre-existing EBS volumes to an
instance, we would do that as follows:
```
resource "aws_instance" "web" {
ami = "ami-21f78e11"
availability_zone = "us-west-2a"
instance_type = "t1.micro"
tags {
Name = "HelloWorld"
}
}
data "aws_ebs_volume" "ebs_volume" {
filter {
name = "size"
values = ["${aws_ebs_volume.example.size}"]
}
filter {
name = "availability-zone"
values = ["${aws_ebs_volume.example.availability_zone}"]
}
filter {
name = "tag:Name"
values = ["TestVolume"]
}
}
resource "aws_volume_attachment" "ebs_att" {
device_name = "/dev/sdh"
volume_id = "${data.aws_ebs_volume.ebs_volume.id}"
instance_id = "${aws_instance.web.id}"
skip_destroy = true
}
```
The issue here is that when we run a terraform destroy command, the volume tries to get detached from a running instance and goes into a non-responsive state. We would have to force_destroy the volume at that point and risk losing any data on it.
This PR introduces the idea of `skip_destroy` on a volume attachment. tl;dr:
We want the volume to be detached from the instane when the instance itself has been destroyed. This way the normal shut procedures will happen and protect the disk for attachment to another instance
Volume Attachment Tests:
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSVolumeAttachment_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/11/02 00:47:27 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSVolumeAttachment_ -timeout 120m
=== RUN TestAccAWSVolumeAttachment_basic
--- PASS: TestAccAWSVolumeAttachment_basic (133.49s)
=== RUN TestAccAWSVolumeAttachment_skipDestroy
--- PASS: TestAccAWSVolumeAttachment_skipDestroy (119.64s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 253.158s
```
EBS Volume Tests:
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSEBSVolume_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/11/02 01:00:18 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSEBSVolume_ -timeout 120m
=== RUN TestAccAWSEBSVolume_importBasic
--- PASS: TestAccAWSEBSVolume_importBasic (26.38s)
=== RUN TestAccAWSEBSVolume_basic
--- PASS: TestAccAWSEBSVolume_basic (26.86s)
=== RUN TestAccAWSEBSVolume_NoIops
--- PASS: TestAccAWSEBSVolume_NoIops (27.89s)
=== RUN TestAccAWSEBSVolume_withTags
--- PASS: TestAccAWSEBSVolume_withTags (26.88s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 108.032s
```
* Update volume_attachment.html.markdown
Radek Simko