-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Conversation
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.
Looks really good! Some comments / ideas.
Also, can you verify whether the feature names are needed for the Postgres Aurora engine without a version? |
@shivlaks can you resolve the conflicts with the current |
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.
Overall looks great!
Couple of minor questions before I give my 'ShipIt' 🙂
if (options.s3ImportRole && !(config.features?.s3Import)) { | ||
throw new Error (`s3Import is not supported for engine: ${this.engineVersion?.fullVersion}. Use an engine version that supports the s3Import feature.`); | ||
} | ||
if (options.s3ExportRole && !(config.features?.s3Export)) { |
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 of ClusterEngineConfig
. I wonder whether a better strategy would be to only return them if s3ImportRole
/ s3ExportRole
was passed in ClusterEngineBindOptions
...?
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?
This change introduces S3 import/export for DatabaseInstances, the same as what currently exists today for DatabaseClusters. This change was heavily influenced by #10132 (the work to introduce feature names for DatabaseCluster), and steals patterns and names heavily from it. **Implementation Notes:** * Unlike for clsuters, for instances, the feature names are required; if the feature name doesn't exist, we shouldn't be creating the role. * For both Oracle and SQL Server, all current/active versions support the same feature names. This simplified the implementation quite a bit. * I opted **not** to support features for the deprecated Oracle versions. * I moved the `setupS3ImportExport` helper function into a utils class. One quirk of the SQL Server requirement is that you must create an OptionGroup with only one role (for both import & export). Oracle, likewise, has a single feature for both import and export. So I opted to default to creating a single role (if necessary) for both import and export. Open to challenges on this. * The `OptionGroup` class needed some rework to be able to make the list of configurations dynamic. I then had to do some light tweaking to ensure backwards compatibility with the connections property. fixes #4419
This change introduces S3 import/export for DatabaseInstances, the same as what currently exists today for DatabaseClusters. This change was heavily influenced by #10132 (the work to introduce feature names for DatabaseCluster), and steals patterns and names heavily from it. **Implementation Notes:** * Unlike for clsuters, for instances, the feature names are required; if the feature name doesn't exist, we shouldn't be creating the role. * For both Oracle and SQL Server, all current/active versions support the same feature names. This simplified the implementation quite a bit. * I opted **not** to support features for the deprecated Oracle versions. * I moved the `setupS3ImportExport` helper function into a utils class. One quirk of the SQL Server requirement is that you must create an OptionGroup with only one role (for both import & export). Oracle, likewise, has a single feature for both import and export. So I opted to default to creating a single role (if necessary) for both import and export. Open to challenges on this. * The `OptionGroup` class needed some rework to be able to make the list of configurations dynamic. I then had to do some light tweaking to ensure backwards compatibility with the connections property. fixes #4419
… s3Export buckets
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.
Looks great! A few last notes if you want to hear them 🙂
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
* feat(rds): S3 import and export for DatabaseInstances This change introduces S3 import/export for DatabaseInstances, the same as what currently exists today for DatabaseClusters. This change was heavily influenced by #10132 (the work to introduce feature names for DatabaseCluster), and steals patterns and names heavily from it. **Implementation Notes:** * Unlike for clusters, for instances, the feature names are required; if the feature name doesn't exist, we shouldn't be creating the role. * For both Oracle and SQL Server, all current/active versions support the same feature names. This simplified the implementation quite a bit. * I opted **not** to support features for the deprecated Oracle versions. * I moved the `setupS3ImportExport` helper function into a utils class. One quirk of the SQL Server requirement is that you must create an OptionGroup with only one role (for both import & export). Oracle, likewise, has a single feature for both import and export. So I opted to default to creating a single role (if necessary) for both import and export. Open to challenges on this. * The `OptionGroup` class needed some rework to be able to make the list of configurations dynamic. I then had to do some light tweaking to ensure backwards compatibility with the connections property. fixes #4419
When the
s3ImportBuckets
ors3ExportBuckets
properties are set, we also needto include the name of the feature for the DB instance that the IAM role is to be associated with.
Excluding the feature name causes a deploy-time failure as follows:
Added an
EngineFeatures
struct to specify the feature name fors3Import
ands3Export
Closes #4419
Closes #8201
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license