-
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(logs): delete associated log group when stack is deleted #21113
Conversation
Pull request has been modified.
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 your responses. Please see my additional comments below.
I realized that I jumped right into this review without also saying thank you for your contribution! This feature will be super helpful so we appreciate you taking it on! |
Pull request has been modified.
…into delete-logs-clean
Pull request has been modified.
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.
Just a few minor things, mostly formatting, but also the arn for long groups wasn't quite right. Neediness that, I think this looks ready to go.
@@ -93,6 +99,8 @@ export class LogRetention extends Construct { | |||
base: retryOptions.base?.toMilliseconds(), | |||
} : undefined, | |||
RetentionInDays: props.retention === RetentionDays.INFINITE ? undefined : props.retention, | |||
//only add RemovalPolicy if it is set to DESTROY | |||
RemovalPolicy: props.removalPolicy && props.removalPolicy === cdk.RemovalPolicy.DESTROY ? props.removalPolicy : undefined, |
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.
There's no reason here to not just pass props.removalPolicy
here.
RemovalPolicy: props.removalPolicy && props.removalPolicy === cdk.RemovalPolicy.DESTROY ? props.removalPolicy : undefined, | |
RemovalPolicy: props.removalPolicy, |
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.
When I wrote this line I thought only add RemovalPolicy if it is set to DESTROY(not add it if it is undefined or set RETAIN), so it is more reasonable to set it as it is?
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 later checking against RemovalPolicy.DESTROY
, which kind of does make it so that you don't need RemovalPolicy.RETAIN
but there's no reason to add this extra logic here. It's better to just pass the value as input by the user. You're not getting any benefit from the extra logic and it opens up the possibility of more failure points when more logic is introduced.
resources: [cdk.Stack.of(this).formatArn({ | ||
service: 'logs', | ||
resource: 'log-group', | ||
resourceName: props.logGroupName+':*', |
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.
resourceName: props.logGroupName+':*', | |
resourceName: `${props.logGroupName}:*`, |
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.
After I removed the ':*', I manually deploy and destroy the stack in integ.log-retention.ts. However, the destroy failed, the error message is: the loggroup is not allowed to delete. After I added the ':*' again, the destroy succeeded. I found the arn of log group is 'arn:aws:logs:us-east-1:account-id:log-group:logRetentionLogGroup:*' from the cloud watch
.
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.
OK. I was incorrect here, but let's at least us better string formatting. See my edited suggestion.
Pull request has been modified.
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.
@YichenQian09 Just a few more issues/updates from last review. This is very much almost ready to go.
@@ -93,6 +99,8 @@ export class LogRetention extends Construct { | |||
base: retryOptions.base?.toMilliseconds(), | |||
} : undefined, | |||
RetentionInDays: props.retention === RetentionDays.INFINITE ? undefined : props.retention, | |||
//only add RemovalPolicy if it is set to DESTROY | |||
RemovalPolicy: props.removalPolicy && props.removalPolicy === cdk.RemovalPolicy.DESTROY ? props.removalPolicy : undefined, |
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 later checking against RemovalPolicy.DESTROY
, which kind of does make it so that you don't need RemovalPolicy.RETAIN
but there's no reason to add this extra logic here. It's better to just pass the value as input by the user. You're not getting any benefit from the extra logic and it opens up the possibility of more failure points when more logic is introduced.
resources: [cdk.Stack.of(this).formatArn({ | ||
service: 'logs', | ||
resource: 'log-group', | ||
resourceName: props.logGroupName+':*', |
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.
OK. I was incorrect here, but let's at least us better string formatting. See my edited suggestion.
Pull request has been modified.
Co-authored-by: Kendra Neil <[email protected]>
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 good! Thanks for all your work on this!
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). |
@YichenQian09 This is great PR... Now I just need to track down all the orphaned Log Groups pre-this-PR lol. Looking forward to the next cdk release. 👍 |
@TheRealAmazonKendra |
) ---- Motivation: The log group created by LogRetention lingers after the stack is deleted. This commit allows users to choose whether to retain or destroy associated logs of the deleted stack. Use case: To avoid having hundreds of dead log groups after the stack is deleted. most salient design aspects: Added an enum LogDeletionPolicy and set LogDeletionPolicy in the LogRetetion custom resource. Added an API deleteLogGroup and added an event 'Delete' to the handler of LogRetetion to delete the log group. closes [aws#11549](aws#11549) ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Cool! Now I guess we need to add |
) ---- Motivation: The log group created by LogRetention lingers after the stack is deleted. This commit allows users to choose whether to retain or destroy associated logs of the deleted stack. Use case: To avoid having hundreds of dead log groups after the stack is deleted. most salient design aspects: Added an enum LogDeletionPolicy and set LogDeletionPolicy in the LogRetetion custom resource. Added an API deleteLogGroup and added an event 'Delete' to the handler of LogRetetion to delete the log group. closes [aws#11549](aws#11549) ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Am I right in my understanding that this PR doesn't actually change anything that can be done in CDK as there isn't a property that can be set on a lambda to change the associated log group's removal policy? So it further requires #21804 to be done in order to achieve the statement of "This commit allows users to choose whether to retain or destroy associated logs of the deleted stack."? |
This PR allows automatically deleting log groups created by logRetention by setting RemovalPolicy. The logGroup created by the lambda function will not be deleted. For example, if we create a logGroup named logRetentionLogGroup using logRetention and set removalPolicy to “destroy”, the second logGroup in the picture will be deleted, but the first will not. Please reply to this if I misunderstand your question or if you have further questions. Thanks! |
Thanks for your reply @YichenQian09. So as I now understand it, this PR will allow Log Groups that are explictly defined in the CDK script to be deleted as part of a stack delete (assuming removalPolicy="destroy"). But a Log Group that is implicitly created (e.g. due the presence of a Lambda function in the script) will not be deleted - hence why #21804 is still open. Hope that's right - thanks for clarifying! |
Motivation: The log group created by LogRetention lingers after the stack is deleted. This commit allows users to choose whether to retain or destroy associated logs of the deleted stack.
Use case: To avoid having hundreds of dead log groups after the stack is deleted.
most salient design aspects:
Added an enum LogDeletionPolicy and set LogDeletionPolicy in the LogRetetion custom resource. Added an API deleteLogGroup and added an event 'Delete' to the handler of LogRetetion to delete the log group.
closes #11549
All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license