-
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
feat(lambda): configurable retries for log retention custom resource #8258
feat(lambda): configurable retries for log retention custom resource #8258
Conversation
This prevents throttling issues on stacks with a lot of Lambdas. fixes aws#8257
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
// Ensure we do not run into throttling issues when deploying stack(s) with a lot of Lambdas. | ||
const retryOptions = { maxRetries: 6, retryDelayOptions: { base: 300 }}; |
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.
How about making this configurable here -
export interface LogRetentionProps { |
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, that makes sense. Do you mean something like this:
- Add retry options to
LogRetentionProps
:
export interface LogRetentionProps {
readonly logGroupName: string;
readonly retention: logs.RetentionDays;
readonly role?: iam.IRole;
readonly logGroupRetryOptions?:LogGroupRetryOptions;
}
export interface LogGroupRetryOptions {
readonly maxRetries?: number;
readonly retryDelayOptions?: {
readonly base?: number
readonly customBackoff?: (retryCount: number, err?: Error) => number
}
}
-
Allow the retry options to be configured in the Lambda by adding the
LogGroupRetryOptions
property also inFunctionOptions
. -
Use the retry options in the log retention provider Lambda.
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 don't need to do #2.
Once defined in LogRetentionProps
, pass it into the properties
key and it should be available in the provider lambda. Just like the other values under properties
.
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 understand that, but I guess the goal here is to also make the retry options configurable via the Lambda props? So when a CDK users creates a Lambda, they can also specify the retry options.
The logRetention
and logRetentionRole
props are also part of FunctionOptions
to enable something similar.
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.
@nija-at Just checking, does my previous comment makes sense? I'd like to continue and obviously create a wonderful PR to fix the issue 🙂
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.
Yes, something like that makes sense. Thanks for explaining.
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.
Made the changes, please check the PR description for additional details on implementation choices.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
Setting this back to request changes
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
… into log-retention-rate-exceeded-error
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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 making the changes. My initial comments below.
* Retry options for creating CloudWatch log groups. Deploying many Lambdas | ||
* with log retention resources may result in rate limit issues when creating | ||
* CloudWatch Log groups. The retry options allow you to customize the retry | ||
* options in order to successfully create these. |
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.
Sufficient to just document what these options are. There can be many reasons to use them.
Something like this -
* Retry options for creating CloudWatch log groups. Deploying many Lambdas | |
* with log retention resources may result in rate limit issues when creating | |
* CloudWatch Log groups. The retry options allow you to customize the retry | |
* options in order to successfully create these. | |
* When log retention is specified, a custom resource attempts to create the CloudWatch log group. | |
* These options control the retry policy when interacting with CloudWatch APIs. |
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.
Agree, will change that.
@@ -2,15 +2,16 @@ | |||
|
|||
// eslint-disable-next-line import/no-extraneous-dependencies | |||
import * as AWS from 'aws-sdk'; | |||
import { LogRetentionRetryOptions } from '../log-retention'; |
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 don't think this will work, the lambda function execution should fail. Did you try deploying a stack that used this?
This file gets deployed as a lambda function during stack deployment. The CDK code is not available there and it should not be.
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 linked it using a postinstall hook in my local test project. Then it works (I guess since it's just an interface that doesn't add any logic to the deployed lambda function). But this is indeed incorrect, I'll fix it.
@@ -69,6 +94,7 @@ export class LogRetention extends cdk.Construct { | |||
properties: { | |||
ServiceToken: provider.functionArn, | |||
LogGroupName: props.logGroupName, | |||
LogRetentionRetryOptions: props.logRetentionRetryOptions, |
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 Retry
or SdkRetry
. We're already in the context of LogRetention.
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, will change
/** | ||
* The maximum amount of retries. | ||
* | ||
* @default - AWS SDK default |
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.
We usually document the default, even if it comes from a dependency
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.
Hmmm, yeah I can change that, but left it like this on purpose. How will you make sure it stays in sync?
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.
It's unlikely the SDK's defaults change. Changing so may break existing customers using the CLI whose applications work because of a given set of defaults, so this is likely to be considered a breaking change.
It may change on the next major version but we have better control over that from the import statements.
* | ||
* @default - AWS SDK default | ||
*/ | ||
readonly base?: number; |
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.
Use Duration
type from the @aws-cdk/core
module.
@@ -26,6 +26,31 @@ export interface LogRetentionProps { | |||
* @default - A new role is created | |||
*/ | |||
readonly role?: iam.IRole; | |||
|
|||
/** | |||
* Retry options for managing CloudWatch log groups. |
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.
maybe this?
* Retry options for managing CloudWatch log groups. | |
* Retry options for all AWS API calls. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
All review comments addressed, please review again. |
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! Good stuff with this PR.
Couple of small suggestions to polish up.
function parseRetryOptions(rawOptions: any) { | ||
const retryOptions: { maxRetries?: number, retryOptions?: { base?: number } } = {}; |
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.
Might be nice to take advantage of type checking (instead of using any
) and define a type like
interface SdkRetryOptions {
readonly maxRetries?: number;
retryOptions?: AWS.RetryDelayOptions;
}
parseRetryOptions
will return this type and the options parameter in APIs like createLogGroupSafe
and setRetentionPolicy()
can be set to this type.
Tweak comment aws#8258 Co-authored-by: Niranjan Jayakar <[email protected]>
aws#8258 Co-authored-by: Niranjan Jayakar <[email protected]>
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
… into log-retention-rate-exceeded-error
Added your suggestions. Hopefully it's merge worthy now 🙂 |
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 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 |
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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This prevents throttling issues on stacks with a lot of Lambdas.
fixes #8257
Implemented configurable
maxRetries
andbase
properties as part of the LogRetentionRetryOptions. The AWS SDK also supports specifying a customBackoff function. I skipped that as it's hard to implement in the current setup (impossible to provide a callback function in the event JSON).By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license