Storage Gateway Upload Buffer creates resource but "Provider produced inconsistent apply"

[bpsi3m3ns]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.24

• provider.aws v2.54.0
• provider.external v1.2.0
• provider.local v1.4.0
• provider.random v2.2.1
• provider.template v2.1.2

Affected Resource(s)

• aws_aws_storagegateway_upload_buffer

Terraform Configuration Files

resource "aws_storagegateway_gateway" "master_gateway" {
  depends_on = [aws_instance.master-gateway-instance]
  gateway_name = "${var.name_prefix}-gate1-${var.name_suffix}"
  gateway_timezone = "GMT-7:00"
  gateway_type     = "CACHED"
  activation_key   = "${data.external.master_activation_key.result["key"]}"
  tags = var.tags

  # The activation keys change periodically, but once the gateway is created they don't matter. Ignore them
  lifecycle {
    ignore_changes = [
      activation_key,
    ]
  }
}
data "aws_storagegateway_local_disk" "master-buffer" {
  disk_node = aws_volume_attachment.master-buffer-mount.device_name
  gateway_arn = aws_storagegateway_gateway.master_gateway.arn
}

resource "aws_storagegateway_upload_buffer" "master-buffer" {
  disk_id = data.aws_storagegateway_local_disk.master-buffer.id
  gateway_arn = aws_storagegateway_gateway.master_gateway.arn
}

resource "aws_volume_attachment" "master-buffer-mount" {
  device_name = "/dev/xvdc"
  volume_id = "${aws_ebs_volume.master-buffer.id}"
  instance_id = "${aws_instance.master-gateway-instance.id}"

Debug Output

Error: Provider produced inconsistent result after apply

When applying changes to
module.test_cluster.aws_storagegateway_upload_buffer.master-buffer, provider
"registry.terraform.io/-/aws" produced an unexpected new value for was
present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Panic Output

Expected Behavior

Apply succeeded

Actual Behavior

Master buffer was successfully created, but terraform displayed the above error. The subsequent apply yielded another error, as the disk had indeed been successfully allocated:

Error: error adding Storage Gateway upload buffer: InvalidGatewayRequestException: The specified disk is already allocated.
{
Error_: {
ErrorCode: "DiskAlreadyAllocated"
},
Message_: "The specified disk is already allocated."
}

on ../modules/storage-gateway/main.tf line 72, in resource "aws_storagegateway_upload_buffer" "master-buffer":
72: resource "aws_storagegateway_upload_buffer" "master-buffer" {

Steps to Reproduce

1. terraform apply

Important Factoids

References

• #0000

[ewbankkit]

This looks like an "eventual-consistency" issue. The resource is created successfully but when Terraform turns around and reads the resource, the service API cannot yet find the resource.

[DrFaust92]

I ran tests several times to try and recreate this and was not able to. i can add add a retry to read the resource right after creating before the resource Read function. its going to be a "dumb" check as there is not status attribute or anything else similar let users know the status of the resource

[bflad]

The error messaging was fixed in version 3.32.0, support for cached gateways in the resource (via a new disk_path argument) is pending here: #18313

[ghost]

This has been released in version 3.34.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!