Resource aws_volume_attachment fails on already attached volume

[dmytroleonenko]

Terraform Version

Terraform v0.11.7
+ provider.aws v1.22.0
+ provider.chef v0.1.0
+ provider.null v1.0.0
+ provider.spotinst v1.1.1
+ provider.template v1.0.0

Despite #11060 should fix my issue it doesn't for some reason.
I'm converting instances from using ebs_volume defined within an aws_instance to separate aws_ebs_volume + aws_volume_attachment. I have two instances each with one volume attached. One aws_volume_attachment detected that the volume is already attached but the other didn't.
In my case volume vol-0e2d99f406bc45149 is attached to instance i-05f6534e73fa4e46f
It looks like this:

Acquiring state lock. This may take a few moments...
data.terraform_remote_state.main: Refreshing state...
data.aws_ami.default_centos: Refreshing state...
aws_instance.mysql-test[0]: Refreshing state... (ID: i-05f6534e73fa4e46f)
aws_instance.mysql-test[1]: Refreshing state... (ID: i-06b214cd786d4df49)
aws_ebs_volume.mysql-test_mysql[0]: Refreshing state... (ID: vol-0e2d99f406bc45149)
aws_ebs_volume.mysql-test_mysql[1]: Refreshing state... (ID: vol-0e3e280c0b5cbfd9a)
aws_volume_attachment.mysql-test_mysql_ebs_attachment[1]: Refreshing state... (ID: vai-2917963461)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
  ~ update in-place

Terraform will perform the following actions:

  + aws_volume_attachment.mysql-test_mysql_ebs_attachment[0]
      id:           <computed>
      device_name:  "sdb"
      instance_id:  "i-05f6534e73fa4e46f"
      skip_destroy: "true"
      volume_id:    "vol-0e2d99f406bc45149"

  ~ aws_volume_attachment.mysql-test_mysql_ebs_attachment[1]
      skip_destroy: "" => "true"


Plan: 1 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_volume_attachment.mysql-test_mysql_ebs_attachment[0]: Creating...
  device_name:  "" => "sdb"
  instance_id:  "" => "i-05f6534e73fa4e46f"
  skip_destroy: "" => "true"
  volume_id:    "" => "vol-0e2d99f406bc45149"
aws_volume_attachment.mysql-test_mysql_ebs_attachment[1]: Modifying... (ID: vai-2917963461)
  skip_destroy: "" => "true"
aws_volume_attachment.mysql-test_mysql_ebs_attachment[1]: Modifications complete after 0s (ID: vai-2917963461)
aws_volume_attachment.mysql-test_mysql_ebs_attachment.0: Still creating... (10s elapsed)
Releasing state lock. This may take a few moments...

Error: Error applying plan:

1 error(s) occurred:

* aws_volume_attachment.mysql-test_mysql_ebs_attachment[0]: 1 error(s) occurred:

* aws_volume_attachment.mysql-test_mysql_ebs_attachment.0: [WARN] Error attaching volume (vol-0e2d99f406bc45149) to instance (i-05f6534e73fa4e46f), message: "vol-0e2d99f406bc45149 is already attached to an instance", code: "VolumeInUse"

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Expected Behavior

aws_volume_attachment just have to appear in the state if the volume is already attached to the instance

Actual Behavior

terraform tries to attach the volume to the instance despite it is already attached

References

• provider/aws: Succeed creating aws_volume_attachment if identical attachment exists #11060

[dmytroleonenko]

I think I found the issue. The thing is that device-name should match exactly. While you can create an instance and pass "sdb" as a device name your aws_volume_attachment should specify exactly "/dev/sdb", not just "sdb". Otherwise, aws-provider filter will return nothing and terraform will try to create the resource again.
I'll close it for now

#reference
https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_volume_attachment.go#L71

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.