Closed ghost closed 2 months ago
Is this similar to #671 #17096?
It is! Thanks for pointing me that way. The symptom is different but the solution may well end up being the same. I had a read through that thread and your PR to add a separate GSI resource (https://github.com/hashicorp/terraform-provider-aws/pull/22513). I can understand @ewbankkit's reasoning in rejecting the PR. At the same time, we're currently in a situation where Terraform fundamentally isn't really usable for managing a provisioned DynamoDB table in the context of a modern CD-based workflow. We use TF for all our infra at the moment but we're looking into Serverless Framework this week in part because we don't want to standardise on TF for full serverless services because of this bug. (Obviously Serverless may also have the same issue because of how the DynamoDB API is structured - we'll have to find out! Regardless, this is a real problem for our team and I'm sure it is for others too.)
Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.
If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!
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.
Community Note
Description
Currently, it's impossible to use terraform to cleanly create a new DynamoDB table with replicas or GSIs unless its billing mode is
PAY_PER_REQUEST
. The reason for this is that:This leads to a circular dependency, in which it's impossible to create a table using autoscaling and replicas/GSIs all in one go using proper terraform. There are two workarounds, both bad.
Using two
apply
sThis workaround is described in a comment on an earlier issue on the same subject, here.
apply
: Create aPROVISIONED
table with no replicas or GSIs, plus create autoscaling resources applying to the table (one each ofaws_appautoscaling_target
andaws_appautoscaling_policy
for reads, and one each for writes)apply
: Update the table to add replicas and GSIsThe advantage of this approach is that everything you create is in the terraform state so subsequent
plan
andapply
operations will use and return correct information. The disadvantage is that it requires running multipleapply
s and patching code in between, which is unpleasant at the best of times and clearly impossible in a CI/CD scenario.Using a
null_resource
with a local provisionerYou create the table with autoscaling but no replicas. You then have a
null_resource
whichdepends_on
the table and the autoscaling resources. Thisnull_resource
uses the AWS CLI in a local provisioner to create the replica tables and GSIs.This approach has the advantage of only requiring one
apply
and no ad hoc code patching, so can be used in CI/CD. However, the replica tables and GSIs you create are effectively not in IaC - they won't be modified by subsequent changes to config, nor will they be torn down when you run adestroy
. Plus, any terraform code changes that will affect them won't be shown in aplan
output. This approach is therefore also very suboptimal.New or Affected Resource(s)
Existing:
aws_dynamodb_table
Potential new:
aws_dynamodb_replica_table
aws_dynamodb_global_secondary_index
Potential Terraform Configuration
The workaround shown above relies on the fact that you can add replicas to an existing table without recreating it. My suggestion, then, would be to add a new resource to the provider which does this.
I've added an example config here for how the new resource would work.
Using new resources here would allow for multiple API calls to take place under the hood, circumventing the need for two
apply
s.To be clear - this is just one suggested solution to this problem. I've got no attachment to any particular solution but this seemed like a simple way to break the architectural deadlock around this.
References