(aws-rds): DatabaseCluster should default `auto_minor_version_upgrade` to `False` if engine version is pinned
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
This may not be _truly_ a bug, but it is not an ideal setup.
When using `aws_rds.DatabaseCluster`, I had a failing over-the-top deploy yesterday because the Aurora PostgreSQL version had been upgraded outside of the CFN stack. I was unaware that this was a behaviour, especially as I had specifically targeted a version of PostgreSQL.
I eventually realised there is the flag `auto_minor_version_upgrade` which I'd not set, but I noticed that its default value is `True`.
What I think would be more user friendly is if this value defaults to `False` **if** `engine` has a version specified.
### Reproduction Steps
```python
from aws_cdk import aws_rds
# Specify an RDS Cluster with a Version set like so
aws_rds.DatabaseCluster(
self,
id="rds-cluster",
engine=aws_rds.DatabaseClusterEngine.aurora_postgres(
version=aws_rds.AuroraPostgresEngineVersion.VER_10_12
),
...
)
...
```
### What did you expect to happen?
Deploying the stack **without** further changes to the `DatabaseCluster` construct would result in a successful deploy.
### What actually happened?
The deploy failed with the following error message:
```
23/42 |4:47:39 PM | UPDATE_FAILED | AWS::RDS::DBInstance | prod-downloader-rds/Instance2 (proddownloaderrdsInstance2BE42B470) The specified DB Instance is a member of a cluster. Modify the DB engine version for the DB Cluster using the ModifyDbCluster API (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: fe271c1d-16c8-4acf-928e-dd93574d7ac4; Proxy: null)
createInstances (/tmp/jsii-kernel-0VxvEJ/node_modules/@aws-cdk/aws-rds/lib/cluster.js:360:26)
\_ new DatabaseCluster (/tmp/jsii-kernel-0VxvEJ/node_modules/@aws-cdk/aws-rds/lib/cluster.js:201:34)
\_ /tmp/tmpbizvy7oq/lib/program.js:8154:58
\_ Kernel._wrapSandboxCode (/tmp/tmpbizvy7oq/lib/program.js:8582:24)
\_ Kernel._create (/tmp/tmpbizvy7oq/lib/program.js:8154:34)
\_ Kernel.create (/tmp/tmpbizvy7oq/lib/program.js:7895:29)
\_ KernelHost.processRequest (/tmp/tmpbizvy7oq/lib/program.js:9479:36)
\_ KernelHost.run (/tmp/tmpbizvy7oq/lib/program.js:9442:22)
\_ Immediate._onImmediate (/tmp/tmpbizvy7oq/lib/program.js:9443:46)
\_ processImmediate (internal/timers.js:461:21)
```
When I checked the RDS Console, I could indeed see that even though my Stack was deployed with `10_12` as the version, it had been upgraded from underneath me to `10_14`, breaking my deployment.
### Environment
- **CDK CLI Version: 1.105.0 (build 4813992)**
- **Framework Version: 1.105.0**
- **Node.js Version: v12.22.1**
- **OS: Ubuntu 20.04.2**
- **Language (Version): Python 3.8.6**
### Other
Following on from a discussion with @skinny85 here https://cdk-dev.slack.com/archives/C018XT6REKT/p1625763866267400
---
This is :bug: Bug Report
Contributor guide
Research direction
Start with the aws_rds.DatabaseCluster construct and the lib/cluster.js entry point shown in the deployment trace, focusing on the auto_minor_version_upgrade default when DatabaseClusterEngine.aurora_postgres receives a pinned version. Reproduce the configuration from the issue and verify that the default is False for pinned engine versions and that deployment succeeds without further construct changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, postgresql, typescript
- Domain
- cloud, databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100