-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DynamoDB: can't change a Table from "Pay Per Request" to "Provisioned" #15318
Comments
Hey @ronakkenia, that's a weird error 🤔. Can you try setting the Thanks, |
Hey @skinny85, thanks for the quick reply. I updated the read and write capacity to both be 6 and oddly enough I get the same error: Changed code to (git diff):
Error
After this, the AWS console shows the DynamoDB to be unchanged. Let me know if there are any other things I can try or other information you would need, thanks! |
@ronakkenia like I wrote, can you try doing this on the Table? Not in Thanks, |
Apologies, I misunderstood/misread. I tried what you actually meant and the CDK command was taking a very long time and then eventually failed with the following (timeout?) error: Changed code to:
Error message:
The Dynamo table in the AWS console looks unchanged compared to previous update attempts and when I try to deploy again to my stack I'm currently in a blocked state because I get an error saying:
And when I try to re-try the update rollback via the AWS console I get the following error for the Dynamo table that this issue is for:
If needed, I can try the suggestion of using set |
Yeah, if you could. I don't think there's much CDK work here - this looks like some peculiarities in the DynamoDB CloudFormation support. |
I was able to retry after fixing the stack drift and finishing the rollback via the console so it was back in the original state. It threw a different kind of error now saying something along the lines of "the autoscaling targets already exist" The following updated in the AWS console:
This was the error message from the command line:
I found some links online pointing to there being existing auto-scaling targets that could be causing issues, but when I run the following command:
I get the following output which looks like the default auto-scaling targets that were made from the table creation code so I am not sure if that's the issue:
Let me know if there is anything else to try or if you think I should bring it up with DynamoDB CloudFormation Support. Thanks! |
Yeah, sorry. You can try more experiments, but I honestly don't think the CDK is doing anything weird here - it looks like the DynamoDB CloudFormation support has some limitations as far as changing the Sorry for the bad experience, but I can't see what CDK can do differently here 😕. |
Same thing experienced by @DennisSSDev in #16302. @DennisSSDev any ideas what CDK can do here? Would a Custom Resource that can perform AWS API calls possibly help here? |
Does this issue only occur if I did a similar test with without First, I deployed my example stack with this table. const table = new Table(this, 'MyTable', {
partitionKey: { name: 'id', type: AttributeType.STRING },
billingMode: BillingMode.PAY_PER_REQUEST,
}); In the AWS Console, I checked the DynamoDB Table: Next, I changed my stack to provisioned billing mode and deployed the stack again (update): const table = new Table(this, 'MyTable', {
partitionKey: { name: 'id', type: AttributeType.STRING },
billingMode: BillingMode.PROVISIONED,
});
table.autoScaleWriteCapacity({
minCapacity: 6,
maxCapacity: 11
}).scaleOnUtilization({ targetUtilizationPercent: 75 });
table.autoScaleReadCapacity({
minCapacity: 7,
maxCapacity: 12,
}).scale The stack will be deployed successfully. In the AWS Console, I can see |
I was able to work around this issue by using the Ensure your table's Go back to your CDK code and add any changes you needed to, as now the |
Hey all, yeah as @mrgarcia1998 wrote, that is the workaround that we and a partner team (repeatable workaround 😄 ) ended up using to get around this issue. Since the problem still exists, I'll leave the GitHub issue open. If the project owners see fit, feel free to close it out, but the issue is handled on our end. |
I tried so many things and eventually I think this is what solved the problem on one table (without reverting entirely to const strataTable = new ddb.Table(this, billingMode: 'PROVISIONED', 'Table', { ... }`)
// HACK:
const node = this.table.node.defaultChild as ddb.CfnTable
node.billingMode = 'PROVISIONED'
|
Could be. It should be a very easy change, just making that line: billingMode: this.billingMode, |
None of my proposals above worked. I eventually had to do this too. |
This issue was for the existing Instead, the Be aware that there are additional deployment steps involved in a migration from Here are some other resources to get you started (using
|
description of the bug:
I created a DynamoDB table via CDK in the past with the on-demand capacity and now want to change it to be of type provisioned. I added the CDK TypeScript code to change the billing mode to be provisioned and to add auto-scaling write and read capacity and when trying to deploy this, I get the following error:
Reproduction Steps
Using the following code:
And running the following command:
What did you expect to happen?
The table to be updated to be billing type provisioned and to have the corresponding min/max read/write auto-scaling units.
What actually happened?
The process throws the error listed above and:
Environment
Other
I found a similar issue in the past so I tried to make sure I was using all the most updated versions of everything I could to include any bugfixes that were already merged in for this issue in the past: crossplane-contrib/provider-aws#464
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: