AWS recently announced the ability to set a TTL on items in a DynamoDB. It requires an additional property to be set for the dynamo table, which I'd like to control via Terraform.
aws_dynamodb_tableYeah, I'd use this too.
I guess we'd add a time_to_live_attribute string which names the attribute to use for this? And would we want to have every Read call invoke DescribeTimeToLive even if time_to_live_attribute isn't set, in order to turn it off if it's there?
+1
+1
+1
Hi @danthegoodman! Thanks for this feature request.
@glasser, your characterization of the implementation approach feels right to me. Based on a quick skim of the API docs for this, I think the right mapping would be a new ttl block in the resource which mirrors the structure of TimeToLiveSpecification:
ttl {
attribute_name = "foo"
enabled = true
}
As @glasser noted, it would be important to call DescribeTimeToLive during Read in order to update Terraform's state to match the real resource. Additionally, it looks like changes to the TTL config apply asynchronously so to preserve Terraform's expected behavior (resource changes aren't complete until they are confirmed committed to the real API) it will be necessary for Update to poll DescribeTimeToLive until TimeToLiveStatus settles on either "ENABLED" or "DISABLED" (depending on what direction we're moving in).
The Terraform team isn't likely to work on this in the near future, but if someone had the time and motivation to write a pull request for it we'd be happy to review it.
+1
+1
+1
Merged and released in 0.9.5:
https://github.com/hashicorp/terraform/pull/14104
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.
Most helpful comment
Hi @danthegoodman! Thanks for this feature request.
@glasser, your characterization of the implementation approach feels right to me. Based on a quick skim of the API docs for this, I think the right mapping would be a new
ttlblock in the resource which mirrors the structure ofTimeToLiveSpecification:As @glasser noted, it would be important to call
DescribeTimeToLiveduringReadin order to update Terraform's state to match the real resource. Additionally, it looks like changes to the TTL config apply asynchronously so to preserve Terraform's expected behavior (resource changes aren't complete until they are confirmed committed to the real API) it will be necessary forUpdateto pollDescribeTimeToLiveuntilTimeToLiveStatussettles on either "ENABLED" or "DISABLED" (depending on what direction we're moving in).The Terraform team isn't likely to work on this in the near future, but if someone had the time and motivation to write a pull request for it we'd be happy to review it.