feat(lambda): L2 constructs for SnapStart#26761
Conversation
aws-cdk-automation
left a comment
There was a problem hiding this comment.
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.
the original handler.zip file is corrupted so added a new one
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
|
added a handler-snapstart.zip in integration test for the original handler.zip seems corrupted. Can we confirm if this make sense, then I'll replace the handler.zip with this new zip |
|
Got some strange 503 error in codebuild Doesn't have any problem with yarn build locally. Can anyone help to take a look? |
| codeSigningConfigArn: props.codeSigningConfig?.codeSigningConfigArn, | ||
| architectures: this._architecture ? [this._architecture.name] : undefined, | ||
| runtimeManagementConfig: props.runtimeManagementMode?.runtimeManagementConfig, | ||
| snapStart: this.configureSnapStart(props), |
There was a problem hiding this comment.
Thanks, wil check this out
colifran
left a comment
There was a problem hiding this comment.
@roger-zhangg this is looking pretty good so far! See my comments and let me know if you have any questions.
|
@colifran I've updated per our discussion, please take a look when you have time, thanks! |
| code: lambda.Code.fromAsset(path.join(__dirname, 'handler.zip')), | ||
| runtime: lambda.Runtime.JAVA_11, | ||
| handler: 'example.Handler::handleRequest', | ||
| snapStart: lambda.SnapStartConfig.ON_PUBLISHED_VERSIONS, |
There was a problem hiding this comment.
@roger-zhangg in case you didn't catch this from the build logs, it looks like the build is failing because you changed the class to SnapStartConf, but didn't update it here.
There was a problem hiding this comment.
Thanks for the catch, I'll update it
There was a problem hiding this comment.
Also I wonder is there a local equivalent to this cloud build? So I won't miss next time
There was a problem hiding this comment.
Not that I'm aware of. If I have a failing build I always use the build logs we generate to understand why it's failing. In this case, at the bottom of the build logs it pointed to the README so I knew to check there.
|
Thanks Colin, I think I got what you meant. I'll check out the code first and get to you if I have any problem |
What's the difference in practice with having "a method" instead of having the validation as part of the constructor? We took inspiration from the existing behavior for the VPC Configuration |
|
My main concern about that is: how do customers know what is a property and what is a method? (of course, they will have to look at the documentation). Is there any other property that exists directly in a Lambda function via the API that in CDK is not a field in the constructor? Just so we don't add this as an "exception" from all the other fields that are directly supported. |
|
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
2 similar comments
|
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
|
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
|
@roger-zhangg @valerena sorry for the delay. I will get back to you on this today. @roger-zhangg @valerena I've spent some more time thinking about this and I'm not entirely sure what advantage we gain by making this a method vs. just adding it as a property. After re-reading the initial PR it seems like one of the concerns with making this a property was that there was an assumption that to enable |
|
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
| throw new Error('SnapStart currently only support published versions'); | ||
| } | ||
|
|
||
| if (props.runtime != Runtime.JAVA_11 && props.runtime != Runtime.JAVA_17 ) { |
There was a problem hiding this comment.
@roger-zhangg looks like we're still waiting on some feedback, but pending that the only other change I would make here is to update our Runtime class to have supportsSnapStart as a LambdaRuntimeProp. Then we can add supportsSnapStart as true to any relevant Runtime when it gets added in the future:
aws-cdk/packages/aws-cdk-lib/aws-lambda/lib/runtime.ts
Lines 3 to 26 in 5fef403
We could then change this check to if (!props.runtime.supportsSnapStart) { //... }
|
I think a prop with validation is fine. |
|
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
| // so it can't be checked at function set up time | ||
| // SnapStart supports the Java 11 and Java 17 (java11 and java17) managed runtimes. | ||
| // See https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html | ||
| if (props.snapStart != SnapStartConf.ON_PUBLISHED_VERSIONS) { |
There was a problem hiding this comment.
Last thing and then we can approve this. Can we remove this? The only way a user can use SnapStartConf is as SnapStartConf.ON_PUBLISHED_VERSIONS
colifran
left a comment
There was a problem hiding this comment.
@roger-zhangg Looks good!
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). |
|
It is great to have SnapStart support with CDK, thank you for this feature. I have a question about this feature implementation. Looking through the PR it seems that there is no check verifying that Lambda Versioning is enabled.
IMO it would make sense to either print out a warning, or even raise an error if SnapStart is configured without Versions being enabled. Would it be possible to consider this improvement? |
|
@mriccia One thing to know is that even though SnapStart works on published versions, the configuration is at the function level, and it will mean that all future versions of the function will have SnapStart enabled. So you don't really need to have versioning enabled right now for this to come into play in the future (and it doesn't hurt to activate it before having any version). Having said that, a printed warning related to this was added, not checking the current versioning, but for users to be aware in general: https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-lambda/lib/function.ts#L1316 Does that make sense to you? |
|
That's great @valerena, yes this warning was what I was looking for (apologies for not spotting it in the code!). |
Closes #23153
snapStart: lambda.SnapStartConfig.ON_PUBLISHED_VERSIONS.This value will be converted to
SnapStart: {ApplyOn: 'PublishedVersions',}in template.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license