Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

joe4dev
Copy link
Member

@joe4dev joe4dev commented Mar 12, 2024

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

  • Update deprecated Lambda runtimes (matching the snapshot behavior): Deprecate 6 runtimes and remove them from test execution including Runtime.python3_7, Runtime.nodejs14_x, Runtime.ruby2_7, Runtime.provided, Runtime.go1_x, Runtime.java8
  • Update Lambda runtime snapshots
  • Add Makefile to conveniently clean and build all Lambda common tests
  • Fix all ARM builds such that the Lambda multiruntime tests are now fully ARM compatible.
  • Re-purpose the Golang tests in test_lambda_runtimes.py while re-using the @multiruntime infrastructure

Testing

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).

@joe4dev joe4dev added the semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases label Mar 12, 2024
@joe4dev joe4dev self-assigned this Mar 12, 2024
@joe4dev joe4dev mentioned this pull request Mar 13, 2024
1 task
@coveralls
Copy link

Coverage Status

coverage: 85.699% (+0.009%) from 85.69%
when pulling be6c93b on update-lambda-runtime-deprecations
into 2df0d12 on master.

@joe4dev joe4dev force-pushed the update-lambda-runtime-deprecations branch from be6c93b to 7d2a162 Compare March 14, 2024 10:03
Copy link

github-actions bot commented Mar 15, 2024

LocalStack Community integration with Pro

    2 files  ± 0      2 suites  ±0   1h 31m 46s ⏱️ + 2m 5s
2 704 tests  - 24  2 449 ✅  - 24  255 💤 ±0  0 ❌ ±0 
2 706 runs   - 24  2 449 ✅  - 24  257 💤 ±0  0 ❌ ±0 

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.
tests.aws.services.lambda_.test_lambda_common.TestLambdaCallingLocalstack ‑ test_manual_endpoint_injection[go1.x]
tests.aws.services.lambda_.test_lambda_common.TestLambdaCallingLocalstack ‑ test_manual_endpoint_injection[java8]
tests.aws.services.lambda_.test_lambda_common.TestLambdaCallingLocalstack ‑ test_manual_endpoint_injection[nodejs14.x]
tests.aws.services.lambda_.test_lambda_common.TestLambdaCallingLocalstack ‑ test_manual_endpoint_injection[python3.7]
tests.aws.services.lambda_.test_lambda_common.TestLambdaCallingLocalstack ‑ test_manual_endpoint_injection[ruby2.7]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_echo_invoke[go1.x]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_echo_invoke[java8]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_echo_invoke[nodejs14.x]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_echo_invoke[provided]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_echo_invoke[python3.7]
…
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_runtime_wrapper_invoke[dotnet6]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_runtime_wrapper_invoke[java11]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_runtime_wrapper_invoke[java17]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_runtime_wrapper_invoke[java21]
tests.aws.services.lambda_.test_lambda_common.TestLambdaRuntimesCommon ‑ test_runtime_wrapper_invoke[java8.al2]
tests.aws.services.lambda_.test_lambda_runtimes.TestGoProvidedRuntimes ‑ test_manual_endpoint_injection[provided.al2023]
tests.aws.services.lambda_.test_lambda_runtimes.TestGoProvidedRuntimes ‑ test_manual_endpoint_injection[provided.al2]
tests.aws.services.lambda_.test_lambda_runtimes.TestGoProvidedRuntimes ‑ test_uncaught_exception_invoke[provided.al2023]
tests.aws.services.lambda_.test_lambda_runtimes.TestGoProvidedRuntimes ‑ test_uncaught_exception_invoke[provided.al2]

♻️ This comment has been updated with latest results.

@joe4dev joe4dev force-pushed the update-lambda-runtime-deprecations branch 2 times, most recently from 354ecd8 to 5cbc19c Compare March 18, 2024 18:21
* 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.
Copy link
Member Author

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)
Copy link
Member Author

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]
Copy link
Member Author

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)
Copy link
Member Author

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.

@joe4dev joe4dev marked this pull request as ready for review March 19, 2024 08:12
@@ -1,9 +1,20 @@
UNAME := $(shell uname -m)
ifeq ($(UNAME),x86_64)
Copy link
Member Author

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 :(

@joe4dev
Copy link
Member Author

joe4dev commented Mar 19, 2024

just noticed that some of the ARM test skips were still there 😬
Fixed and gonna see what fails in the CI now. Will see whether the Java tests need the ARCHITECTURE conditional for the Docker build as well ...

Copy link
Member

@dfangl dfangl left a 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 */))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@joe4dev
Copy link
Member Author

joe4dev commented Mar 19, 2024

The Makefiles were not part of the caching checksum 😬, so the specific Rust build fix was never applied 🙈
Finally, everything is green 🟢 now that Makefile updates invalidate the cache as well 🚀

@joe4dev
Copy link
Member Author

joe4dev commented Mar 19, 2024

Sidenote about the Rust ARM builds:

@joe4dev joe4dev force-pushed the update-lambda-runtime-deprecations branch from 62cc0ab to a3e29bd Compare March 20, 2024 09:04
@joe4dev joe4dev changed the title Update lambda runtime deprecations Update lambda runtime deprecations and fix Lambda ARM builds Mar 20, 2024
@joe4dev joe4dev merged commit 1933c81 into master Mar 20, 2024
@joe4dev joe4dev deleted the update-lambda-runtime-deprecations branch March 20, 2024 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants