-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(rds): support performance insights configuration at cluster level #31385
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
1c091be
to
2a1d34d
Compare
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
@@ -476,14 +476,14 @@ to use for the instance: | |||
declare const vpc: ec2.Vpc; | |||
|
|||
const iopsInstance = new rds.DatabaseInstance(this, 'IopsInstance', { | |||
engine: rds.DatabaseInstanceEngine.mysql({ version: rds.MysqlEngineVersion.VER_8_0_30 }), |
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.
VER_8_0_30 is deprecated.
However, if Performance Insights is enabled at the cluster level, it is not possible to specify a different value for the instance | ||
level than the cluster level. |
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.
If Performance Insights was enabled at cluster and instance level, and the values of the performanceInsightRetention
or performanceInsightEncryptionKey
were different for the cluster and the instance, CFn failed.
If performanceInsightRetention
s are different, CFn occurred:
Resource handler returned message: "PerformanceInsightsRetentionPeriod conflicts with cluster level parameter. ...“
If performanceInsightEncryptionKey
s are different, CFn occurred:
Resource handler returned message: "PerformanceInsightsKMSKeyId conflicts with cluster level parameter. …”
However, if Performance Insights was enabled at cluster and instance level and the values were the same for the cluster and the instance, CFn did not fail.
If the value of enablePerformanceInsights
was different for the cluster and the instance, it did not result in an error. If it was true in the cluster and false in the instance, it did not result in an error but was also enabled in the instance.
===
I wanted to implement validation of this behaviour. However, the instance does not have Performance Insights settings publicly, so it is not accessible from the cluster. Therefore, to implement validation, the structure of the instances had to be changed significantly, so I decided not to do it in this PR.
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.
the structure of the instances had to be changed significantly,
Isn't exposing the props in AuroraClusterInstance
and adding validation in validateClusterInstances
enough? 🤔
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 added the validation, what do you think?
The cluster has a writer and readers as IAuroraClusterInstance
not AuroraClusterInstance
, so I added the variable performanceInsightsEnabled
in IAuroraClusterInstance
interface.
And the legacyCreateInstances
function for the database cluster is not a method, I also added a public variable performanceInsightsEnabled
in DatabaseClusterNew
.
However, if Performance Insights is enabled at the cluster level, it is not possible to specify a different value for the instance | ||
level than the cluster level. |
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.
the structure of the instances had to be changed significantly,
Isn't exposing the props in AuroraClusterInstance
and adding validation in validateClusterInstances
enough? 🤔
Thanks for your review. |
throw new Error(`\`performanceInsightEncryptionKey\` for each instance must be the same as the one at cluster level, got instance '${instance.node.id}': '${instance.performanceInsightEncryptionKey.keyArn}', cluster: '${this.performanceInsightEncryptionKey.keyArn}'`); | ||
} | ||
// Even if both of cluster and instance keys are unresolved, check if they are the same token. | ||
if (compared === TokenComparison.BOTH_UNRESOLVED && clusterKeyArn !== instanceKeyArn) { |
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.
Not sure about the validity of this condition 🤔
Given that we're already ignoring the ONE_UNRESOLVED
case, we could maybe skip the check for BOTH_UNRESOLVED
as well
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 was certainly wondering about this myself because I had never seen such an implementation. However, I thought that if only one of the values is a token, it is impossible to compare them in any way, but if both are tokens, they can be compared by check whether both are the same token.
I thought that excluding this case would diminish the validation as it would mean skipping the most common cases, such as the following. What do you think?
new DatabaseCluster(stack, 'Database', {
engine: DatabaseClusterEngine.AURORA,
vpc,
performanceInsightEncryptionKey: new kms.Key(stack, 'Key1'),
writer: ClusterInstance.provisioned('writer', {
performanceInsightEncryptionKey: new kms.Key(stack, 'Key2'),
}),
});
split split for instanceProps
bf16a1c
to
e5d5463
Compare
I have reflected on your points and replied to them, could you take another look at them? |
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.
Thanks 👍
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.
Thanks for contributing! Left some minor feedbacks
|
||
/** | ||
* Whether Performance Insights is enabled | ||
*/ | ||
readonly performanceInsightsEnabled?: boolean; | ||
|
||
/** | ||
* The amount of time, in days, to retain Performance Insights data. | ||
*/ | ||
readonly performanceInsightRetention?: PerformanceInsightRetention; | ||
|
||
/** | ||
* The AWS KMS key for encryption of Performance Insights data. | ||
*/ | ||
readonly performanceInsightEncryptionKey?: kms.IKey; |
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.
Why do they need to be introduced in the interface?
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.
The reason for this is that in order to validate instance's settings in the DatabaseClusterNew
class, the properties need to be added to the interface. Otherwise, the class cannot access the properties.
see: #31385 (comment)
The writer
and reader
variables are not class type but the interface type (IAuroraClusterInstance
), so added to the interface.
/**
* Perform validations on the cluster instances
*/
private validateClusterInstances(writer: IAuroraClusterInstance, readers: IAuroraClusterInstance[]): void {
if (writer.type === InstanceType.SERVERLESS_V2) {
this.hasServerlessInstance = true;
}
validatePerformanceInsightsSettings(this, {
nodeId: writer.node.id,
performanceInsightsEnabled: writer.performanceInsightsEnabled,
performanceInsightRetention: writer.performanceInsightRetention,
performanceInsightEncryptionKey: writer.performanceInsightEncryptionKey,
});
this.performanceInsightsEnabled = enablePerformanceInsights; | ||
this.performanceInsightRetention = enablePerformanceInsights | ||
? (props.performanceInsightRetention || PerformanceInsightRetention.DEFAULT) | ||
: undefined; | ||
this.performanceInsightEncryptionKey = props.performanceInsightEncryptionKey; |
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.
Why is this needed instead of the old way
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.
This is just to set it to new variables added to the AuroraClusterInstance
instance variables.
L467-469
public readonly performanceInsightsEnabled: boolean;
public readonly performanceInsightRetention?: PerformanceInsightRetention;
public readonly performanceInsightEncryptionKey?: kms.IKey;
Annotations.of(cluster).addWarningV2( | ||
'@aws-cdk/aws-rds:instancePerformanceInsightsOverridden', | ||
`Performance Insights is enabled on cluster '${cluster.node.id}' at cluster level, but disabled for ${target}. `+ | ||
'However, Performance Insights for this instance will also be automatically enabled if enabled at cluster level.', |
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.
should we just throw an error here to match the bebhaviour with the bottom checks?
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.
CFn can deploy with this configuration. It just means that the instance configuration is overridden by the Aurora service layer not CFn.
If it can be deployed as the correct behaviour in CFn but not in CDK, it will block valid deployments. This is why I have made it a warning here.
What do you think?
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.
That's good to know. I agree with your approach instead if it's deployable.
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.
LGTM
Thank you for contributing! Your pull request will be updated from main 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 |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #31375 .
Reason for this change
Properties for Performance Insights at cluster level are supported in L1, but not in L2.
Description of changes
Added the properties in props for Database Cluster.
Description of how you validated changes
Both unit tests and integ tests.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license