-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Update lambda runtime deprecations and fix Lambda ARM builds #10441
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
Conversation
be6c93b
to
7d2a162
Compare
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 1h 31m 46s ⏱️ + 2m 5s Results for commit a3e29bd. ± Comparison against base commit 82bf6e6. This pull request removes 33 and adds 9 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
354ecd8
to
5cbc19c
Compare
* b) creates a `handler.zip` file with a Lambda deployment package | ||
* SHOULD define an `ARCHITECTURE` parameter to overwrite the target architecture (i.e., `x86_64` or `arm64`) | ||
if architecture-specific builds are required (e.g., Dotnet, Golang, Rust). | ||
* By default, the Makefile should build a deployment package with the same architecture as the host. |
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 default behavior is debatable:
- It currently aims for compatibility. For example, the build on a Linux ARM machine should not fail.
- It differs from the default Lambda behavior using
x86_64
by default.
Hence, on multi-architecture platforms (e.g., Apple Silicon), x86_64 builds require a parameter make ARCHITECTURE=x86_64
.
DOCKER_PLATFORM ?= linux/$(ARCHITECTURE) | ||
# The packaging function architecture is x86_64 by default and needs to be set explicitly for arm64 | ||
# https://github.com/aws/aws-extensions-for-dotnet-cli/blob/cdd490450e0407139d49248d94a4a899367e84df/src/Amazon.Lambda.Tools/LambdaDefinedCommandOptions.cs#L111 | ||
FUNCTION_ARCHITECTURE ?= $(ARCHITECTURE) |
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.
Dotnet is a good example why an explicit ARCHITECTURE
flag is needed:
- In general, the
--platform=$(DOCKER_PLATFORM)
flag is needed for cross-architecture on multi-architecture platforms - The Dotnet build specifically requires the
--function-architecture
flag for ARM build. It does not detect the right architecture automatically (unlike Golang builds). Therefore, being consistently verbose clarifies the build options.
|
||
# A temporary list of missing runtimes not yet supported in LocalStack. Used for modular updates. | ||
# TODO: add Dotnet8 runtime | ||
MISSING_RUNTIMES = [Runtime.dotnet8] |
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 should be removed with the follow-up addition in the Dotnet8 PR
return package_path | ||
|
||
# packaging | ||
result = subprocess.run(["make", "build"], cwd=runtime_dir) |
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.
L90 above: We could consider renaming common
to multiruntime to make the reuse a bit more explicit.
@@ -1,9 +1,20 @@ | |||
UNAME := $(shell uname -m) | |||
ifeq ($(UNAME),x86_64) |
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 wished this could be shorter but Ubuntu (in CI) yields aarch64
and macOS yields arm64
, so we need the conditional to standardize the UNAME
architecture :(
just noticed that some of the ARM test skips were still there 😬 |
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.
Great changes, with nice comments to explain the reasoning 🎉
# Top-level Makefile to invoke all make targets in sub-directories | ||
|
||
# Based on https://stackoverflow.com/a/72209214/6875981 | ||
SUBDIRS := $(patsubst %/,%,$(wildcard */)) |
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.
Nice!
The Makefiles were not part of the caching checksum 😬, so the specific Rust build fix was never applied 🙈 |
Sidenote about the Rust ARM builds:
|
Need to validate whether that also works in CI under Ubuntu ?!
62cc0ab
to
a3e29bd
Compare
Motivation
Some deprecated Lambda runtimes are fully phased out at AWS, such that we cannot create snapshots anymore. We need to update our Lambda runtimes lifecycle accordingly.
Changes
Runtime.python3_7, Runtime.nodejs14_x, Runtime.ruby2_7, Runtime.provided, Runtime.go1_x, Runtime.java8
test_lambda_runtimes.py
while re-using the @multiruntime infrastructureTesting
Discussion
Keep supported runtimes in sync with resource browser
❓ Do we need to start offering a dynamic endpoint that lists the supported (and deprecated) runtimes?
Currently, the supported runtimes seem hardcoded. This only works with the latest LocalStack version. Users with older LocalStack versions might face issues.
AWS behavior does not match docs
❓ What do we use as a reference?
Note
This was mainly an issue right during the API updates but now everything looks in sync again.
Snapshot testing reveals that deprecated Lambda runtimes still remain supported much longer than described in the documentation. Therefore, our deprecation warnings are not in sync with AWS (mainly enforced by the unit test
tests.unit.services.lambda_.test_api_utils.TestApiUtils.test_check_runtime
that enforces that our tested runtimes match the supported runtimes). We could remove them from our tests if we value deprecation warning parity higher than current behavior parity (i.e., still being able to create deprecated runtimes).