terraform-provider-aws: DynamoDB TTL Infinitely Out of Sync

DynamoDB tables that have a ttl block with enabled = false will never be able to have their state in sync with the infrastructure.

Terraform Version

Terraform v0.11.3
+ provider.aws v1.9.0
+ provider.template v1.0.0

Affected Resource(s)

  • aws_dynamodb_table

Terraform Configuration Files

provider "aws" {
  region = "us-west-2"
}

resource "aws_dynamodb_table" "dynamodb-composite-gsi-composite" {
  count = 1
  name  = "glen-test-ignore"

  read_capacity  = 10
  write_capacity = 10
  hash_key       = "hi"
  range_key      = "me"

  attribute {
    name = "hi"
    type = "S"
  }

  attribute {
    name = "me"
    type = "N"
  }

  attribute {
    name = "x"
    type = "S"
  }

  attribute {
    name = "y"
    type = "N"
  }

  ttl {
    enabled        = false
    attribute_name = ""
  }

  global_secondary_index {
    name            = "glen-test"
    hash_key        = "x"
    range_key       = "y"
    write_capacity  = "10"
    read_capacity   = "10"
    projection_type = "ALL"
  }
}

Debug Output

https://gist.github.com/goakley/c682bf633544bc71cfbe4367df30bfbf

Expected Behavior

Terraform should have determined that no changes needed to be applied, since the DyanmoDB TTL feature is already disabled on the table.

Actual Behavior

Terraform wants to change the TTL to DISABLED, which will end up being a noop. If this is run (and it will succeed), Terraform will determine that the exact same set of changes will need to be made on the next Terraform run. That is, it will never think that the DynamoDB TTL feature is disabled even though it is.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply
  2. terraform apply

Important Factoids

This example is a simplified version of our production code, which references variables to set the enabled property of the ttl block. Many of our tables don’t use TTL, so enabled is set to false, but this causes Terraform to forever think that the DynamoDB table is out of sync with the Terraform state.

References

None.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 36
  • Comments: 20 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Start having the issue with plugin 2.5.0.

- Downloading plugin for provider "aws" (2.5.0)...

The workaround by christhomas worked.

  ttl {
    # https://github.com/terraform-providers/terraform-provider-aws/issues/3463
    #attribute_name = "${var.ttl_attribute}"
    attribute_name = ""
    enabled        = "${var.enable_ttl}"
  }

Hi @bflad - there’s been a pull request open for this for months ( #3960 ), is there a reason that would be ignored in favour of the team itself triaging this?

Seems that setting the attribute_name = "TimeToExist" like other examples solved the problem. I’m unsure why.

On the terraform docs, you have this example, which you can see the TTL attribute name is “TimeToExist” and this was causing the problem

https://www.terraform.io/docs/providers/aws/r/dynamodb_table.html

When I set the attribute_name = "" the problem went away

Not Working:

ttl { attribute_name = “TimeToExist” enabled = false }

Working:

ttl { attribute_name = “” enabled = false }

Still reproducible on terraform 0.11.8 and aws provider 1.38.

It appears to me that the issue is probably that the AWS API doesn’t return the TTL information, so the tf aws provider doesn’t know whether or not it changed.

If you run aws dynamodb describe-table --table-name <blah> you see there’s no TTL information in the response. So, more like an AWS bug than a terraform provider bug?

Can confirm this bug exists on the latest version:

Terraform v0.12.9
+ provider.aws v2.30.0

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

The fix for this has been merged and will release with version 2.1.0 of the Terraform AWS Provider, likely in the next day or two.

Hi all! Posting a 👍 reaction on the original comment for this issue is the best way to indicate support for it, since we use reaction counts as an input to prioritization. Posting “+1” comments does not have that effect, and also creates notification noise for the people already following this issue.