Skip to content
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

aws-cdk-lib.aws_rds: instance update impossible - collides with storage configuration #27212

Open
schabe77 opened this issue Sep 20, 2023 · 4 comments
Labels
@aws-cdk/aws-rds Related to Amazon Relational Database bug This issue is a bug. effort/medium Medium work item – several days of effort p2

Comments

@schabe77
Copy link
Contributor

Describe the bug

Hi,

I switched my database cluster to the storage configuration mode AURORA_IOPT1 3 weeks ago.

Now I tried to change the instance type. This is my changeset:

Resources
[~] AWS::RDS::DBInstance rds-instance/db-cluster/db-writer rdsinstancedbclusterdbwriterDA345B19
 └─ [~] DBInstanceClass
     ├─ [-] db.r6g.xlarge
     └─ [+] db.serverless
[~] AWS::RDS::DBInstance rds-instance/db-cluster/reader-1 rdsinstancedbclusterreader193075C02
 └─ [~] DBInstanceClass
     ├─ [-] db.r6g.xlarge
     └─ [+] db.serverless

but when I try to deploy the change this error(s) occur:

10:40:13 | UPDATE_FAILED        | AWS::RDS::DBCluster                         | rdsinstancedbcluster1749B05D
Resource handler returned message: "You can't modify the storage type of this DB cluster yet. Try again after 2023-10-02T06:46:24.564Z. (Service: Rds, Status Code: 400, Request ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)" (RequestToken: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, HandlerErrorCode: InvalidRequest)
10:40:19 | UPDATE_FAILED        | AWS::RDS::DBCluster                         | rdsinstancedbcluster1749B05D
Resource handler returned message: "You can't modify the storage type of this DB cluster yet. Try again after 2023-10-02T06:46:24.564Z. (Service: Rds, Status Code: 400, Request ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)" (RequestToken: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, HandlerErrorCode: InvalidRequest)

I my opinion this operation should work, even though I'm still in the mandatory 1 month keep-storage-configuration-period. I don't want to modify the storage configuration, just the instance types. When I do the change via the management console, everything works fine.

Is it possible, that the modify-instance case was not considered when the storage configuration was introduced to cdk (as far as I can see with #25629)? Maybe the modify process tries to set the default storage type on update?

Expected Behavior

I wan't to be able to modify my instance type, even if I'm currently not allowed to change the storage type

Current Behavior

I'm unabel to change the database instance types

Reproduction Steps

create a database cluster, switch storage type, then try to modify the instance type or add a new instance

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.96.2 (build 3edd240)

Framework Version

No response

Node.js Version

v20.6.1

OS

macOs Ventura 13.5 (22G74)

Language

Java

Language Version

OpenJDK Runtime Environment Corretto-17.0.8.8.1 (build 17.0.8.1+8-LTS)

Other information

No response

@schabe77 schabe77 added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Sep 20, 2023
@github-actions github-actions bot added the aws-cdk-lib Related to the aws-cdk-lib package label Sep 20, 2023
@pahud
Copy link
Contributor

pahud commented Sep 20, 2023

So it sounds like you just modified the storage type from console and now you are trying to update the instance type with CDK but failed with the error?

even though I'm still in the mandatory 1 month keep-storage-configuration-period
Can you explain where this restriction comes from?

@pahud pahud added p2 response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. effort/medium Medium work item – several days of effort and removed needs-triage This issue or PR still needs to be triaged. labels Sep 20, 2023
@schabe77
Copy link
Contributor Author

No, I first tried it with cdk - this failed. Then I tried it via Management Console and this worked.

The question regarding the restriction is a good one. When I switched to I/O Optimized there was a warning that it's only possible to switch once per month. I have assumed that this is applied to both directions, but according to this documentation it should be possible to switch back to Aurora Standard at any time: "You can switch from Aurora I/O-Optimized to Aurora Standard at any time.", "You can switch from Aurora Standard to Aurora I/O-Optimized once every 30 days.".

This makes the error message even more confusing.

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Sep 20, 2023
@samhopwell
Copy link

samhopwell commented Sep 26, 2023

I'm also running into this issue while changing a security group of an RDS cluster that was deployed with AURORA_IOPT1.

Within the console the cluster is still showing as configured as AURORA_IOPT1 however during a cdk deploy it fails with "You can't modify the storage type of this DB cluster yet." despite there not being any storage changes listed.

If I remove storage_type from the DatabaseCluster construct this deploys as expected. It is still showing as AURORA_IOPT1 within the console also

@cajual
Copy link

cajual commented Dec 12, 2023

This is an issue for us as well. We've have to introduce custom logic to allow our users to make changes to a database that has aurora-iopt1 enabled.

@moelasmar moelasmar added @aws-cdk/aws-rds Related to Amazon Relational Database and removed aws-cdk-lib Related to the aws-cdk-lib package labels Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-rds Related to Amazon Relational Database bug This issue is a bug. effort/medium Medium work item – several days of effort p2
Projects
None yet
Development

No branches or pull requests

5 participants