-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Handle pending RDS engine version updates #30247
Conversation
Community NoteVoting for Prioritization
For Submitters
|
592bbe5
to
dd79b92
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel good about this, when you do. 👍
This functionality has been released in v4.62.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Description
This change fixes "inconsistent final plan" errors caused by deferred engine version updates (
apply_immediately = false
) in the RDS cluster, cluster instance, and instance resources. Specifically, read operations will now check thePendingModifiedValues
for a non-nilEngineVersion
. If present, and equal to the existing configured value, this will be stored in state to ensure a consistent final plan and avoid persistent diffs until the update takes place during the next maintenance window.Additionally, this change improves the cluster update workflow when there are pending updates by:
EngineVersion
field if the configured and "actual" engine versions differ.DBInstanceParameterGroupName
field any time the value is set.DescribeDBClusters
API, so once set there is no way to detect drift and determine when state does not match the remote value. Sending the value whenever configured avoids errors where the desired value should be sent, but isn't because no drift could be detected. Sending a value that matches the existing remote should have no negative impact.Relations
Closes #29861
Closes #22022
Closes #28219
Relates #30245
References
Output from Acceptance Testing
Failures are unrelated to this change.