Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix(rds): cannot use s3ImportBuckets or s3ExportBuckets with aurora postgres #10132
fix(rds): cannot use s3ImportBuckets or s3ExportBuckets with aurora postgres #10132
Changes from 8 commits
34c0997
2699247
9774ddf
ca46702
fd761df
4d00cfd
d22901f
50e3f58
4620ac1
3a2fa03
cf2c014
9f42b00
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
These
if
s here mean that the unversioned Postgres engine doesn't support S3 import/export at all. Is that true? Have you verified it?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.
you're right that this code precludes supporting these features for the unversioned Postgres version.
The only reason I added these conditions are because it's a latent failure and it felt like adding validation would help users in getting ahead of it.
The reason I left out the unversioned feature support is because we've already marked them deprecated and the feature is not supported today. I didn't think it was a good idea to try and support it and keep that usage going and was hoping to nudge users towards the guidance we're providing in our doc string.
What do you think? is this validation worth it? should we drop it altogether?
This may also affect the default message for the error (should probably drop the
?? <unversioned>
).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.
My opinion is the following: if the RDS service supports it, we should support it as well.
Note that we might also have to "un-deprecate" these fields at some point before CDK v2.0 hits - see the discussion here, which makes fully supporting them even more relevant.
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.
gotcha, I didn't realize we weren't fully convinced that we wanted to keep it marked as
@deprecated
added support for this case and skipped validation if the featurename is supported.
When unversioned is specified, both features are marked as supported. This is true today, but may not be if the version is changed out from underneath. I'm not sure the constant can support it both ways
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 would mark is as supported for both, always (otherwise, this feature has no chance of working with the unversioned engine at all).
Worst comes to worst, it will fail at deploy time, which is fine by me.
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.
Actually, here's a thought.
Today, you always return the features names in the
features
property ofClusterEngineConfig
. I wonder whether a better strategy would be to only return them ifs3ImportRole
/s3ExportRole
was passed inClusterEngineBindOptions
...?Yes, I understand the code in Cluster today uses the feature names only if
s3ImportRole
/s3ExportRole
are !=undefined
... but I wonder whether that will be obvious when we implement other feature names, and whether it's actually better to not return them if they were not requested...Thoughts on this change?