Change AWS_EXECUTION_ENV set in the lambda init binary #10212
Conversation
dfangl
added
the
semver: minor
LocalStack Community integration with Pro 2 files 2 suites 1h 23m 5s ⏱️ Results for commit 46f0936. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Love the new init environment test 🤩
I don't expect people to customize their init environment for LocalStack based on the runtime suffix we had for AWS_EXECUTION_ENV.
Nothing blocking the merge; just added some comments/suggestions (e.g., regarding our internal dev flow).
| @@ -358,10 +358,11 @@ def start(self, env_vars: dict[str, str]) -> None: | |||
| self.container_name, f"{str(get_runtime_client_path())}/.", "/" | |||
| ) | |||
| # tiny bit inefficient since we actually overwrite the init, but otherwise the path might not exist | |||
| if config.LAMBDA_INIT_DEBUG: | |||
| if config.LAMBDA_INIT_BIN_PATH: | |||
There was a problem hiding this comment.
neat idea to decouple debugging from init overwrite. How does it facilitate your workflow?
LAMBDA_INIT_DEBUG was convenient to enable the entire init copying and debugging. I typically commented exec /var/rapid/init in the Lambda init repo under /debugging/init/var/rapid/entrypoint.sh to toggle debugging.
This is still necessary but separating the conditional here would require two steps (+1 toggle) to use debugging 🤔
There was a problem hiding this comment.
(already hit me 😅 when trying to test the changes while having LAMBDA_INIT_BIN_PATH set by default)
There was a problem hiding this comment.
The lambda init path was necessary anyway before. Now you can set only the init path to enable usage of a new lambda init binary without having to setup debugging itself.
You cannot toggle the init copying with the debug variable, but I would suggest using different profiles for this, instead of the toggle of init debug?
I can leave it out from this PR if you do not think it improves usability for developers, but for me it simplifies it, because I more often try out new inits without debugging than with.
There was a problem hiding this comment.
I agree that we should have a way to simplify init testing without debugging 👍
Using profiles makes a lot of sense here 💯 . Then having two entrypoint.sh versions, one for testing (exec /var/rapid/init) and one for debugging makes switching easier. Thanks for sharing 👍
tests/aws/services/lambda_/functions/lambda_process_inspection.py
Outdated
Show resolved
Hide resolved
localstack/services/lambda_/invocation/execution_environment.py
Outdated
Show resolved
Hide resolved
| @@ -696,6 +697,66 @@ def assert_events(): | |||
| ) | |||
| snapshot.match("invoke-result-read-number-after-timeout", result) | |||
|
|
|||
| @markers.aws.validated | |||
There was a problem hiding this comment.
I'm getting this diff when validating against AWS:
>> match key: create-result
(+) /CreateFunctionResponse/LoggingConfig ( {'LogFormat': 'Text', 'LogGroup': '/aws/lambda/<function-name:1>'} )
(Initially wanted to double-check "_AWS_XRAY_DAEMON_ADDRESS": "169.254.79.129", but then noticed this one; might be a very recent update)
There was a problem hiding this comment.
Maybe I did not have botocore updated, thanks for the hint and the double check!
|
Obviously, |
dfangl
force-pushed
the
aws-runtime-env
branch
from
b1c61d0
to
46f0936
Compare
| if self.function_version.config.runtime: | ||
| env_vars["AWS_EXECUTION_ENV"] = f"Aws_Lambda_{self.function_version.config.runtime}" | ||
| env_vars["AWS_EXECUTION_ENV"] = "AWS_Lambda_rapid" |
Motivation
The lambda init binary should have the
AWS_EXECUTION_ENVset toAWS_Lambda_rapid. The setting of the concrete value depending on the runtime will be done in/var/runtime/bootstrap, and is part of the lambda images.Some extensions depend on that value being correct for checking what runtime is running (datadog).
Even though this is a parity adjustment, it is a quite significant change, so I labeled it minor for now.
Changes
AWS_Lambda_rapidLAMBDA_INIT_DEBUGis not set