Navigation Menu
-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Fix docker runtime executor flags #7675
Changes from all commits
ae9fb6d
6fb2525
36493d1
919c144
97ff415
79d27a3
9e8516d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,6 @@ | ||
| import json | ||
| import os | ||
| import platform | ||
| from typing import Literal | ||
|
|
||
| from localstack.utils.common import to_str | ||
|
|
@@ -117,14 +118,16 @@ def get_events(): | |
|
|
||
|
|
||
| def is_old_provider(): | ||
| return ( | ||
| os.environ.get("TEST_TARGET") != "AWS_CLOUD" | ||
| and os.environ.get("PROVIDER_OVERRIDE_LAMBDA") != "asf" | ||
| ) | ||
| return os.environ.get("TEST_TARGET") != "AWS_CLOUD" and os.environ.get( | ||
| "PROVIDER_OVERRIDE_LAMBDA" | ||
| ) not in ["asf", "v2"] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good catch 👍 |
||
|
|
||
|
|
||
| def is_new_provider(): | ||
| return ( | ||
| os.environ.get("TEST_TARGET") != "AWS_CLOUD" | ||
| and os.environ.get("PROVIDER_OVERRIDE_LAMBDA") == "asf" | ||
| ) | ||
| return os.environ.get("TEST_TARGET") != "AWS_CLOUD" and os.environ.get( | ||
| "PROVIDER_OVERRIDE_LAMBDA" | ||
| ) in ["asf", "v2"] | ||
|
|
||
|
|
||
| def is_arm_compatible(): | ||
| return platform.machine() == "arm64" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -180,8 +180,11 @@ def test_container_starts_non_root(self, runner, monkeypatch, container_client): | |
| output = container_client.exec_in_container(config.MAIN_CONTAINER_NAME, ["ps", "-u", user]) | ||
| assert "supervisord" in to_str(output[0]) | ||
|
|
||
| @pytest.mark.skip(reason="skip temporarily until compatible localstack image is on DockerHub") | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. re-enable as soon as the new Docker image is on DockerHub. The update of |
||
| def test_start_cli_within_container(self, runner, container_client): | ||
| output = container_client.run_container( | ||
| # CAVEAT: Updates to the Docker image are not immediately reflected when using the latest image from | ||
| # DockerHub in the CI. Re-build the Docker image locally through `make docker-build` for local testing. | ||
| "localstack/localstack", | ||
| remove=True, | ||
| entrypoint="", | ||
|
|
||

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 think we're nearing the point where we should start writing an abstraction to generate these messages 🤔
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.
(please not in this PR though 😁 )
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.
fully agree 👍
Uh oh!
There was an error while loading. Please reload this page.
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.
@dominikschubert @joe4dev FYI there's a module in ASF that uses botocore for server-side validation, which does validation of constraints that are defined in the spec automatically (the first condition for example is in the spec, the second also): https://github.com/localstack/localstack/blob/master/localstack/aws/protocol/validate.py
the two problems are: defining the conditions that aren't in the spec (easy), and generalizing message creation (hard).
the messages are generally different across services, but some services definitely use the same pattern that we could generalize (i'm assuming there's some internal AWS library for matching constraints). that should definitely go into ASF :-)
we haven't invested in this yet really because in most cases, client-side validation will already take care of anything that's in the spec. so the cases where we would really benefit from this type of validation are fairly rare.
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.
For schema-related things, I agree.
For non-schema validations I think this doesn't make much sense looking at the actual behavior and output we observe from AWS. From what I've seen so far this really is completely service-dependent and even in a single service doesn't always behave in a completely generalizable manner. You often also need service-internal state for these validations.
I'm not 100% sure that we can "cleanly" separate these two though, because I'm not sure they are cleanly separated on the side of AWS as well 😬
Some of the newer services that mostly just have CRUD API might be pretty standard though 🤔
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.
@thrau Thank you for the pointer. I discussed this a few weeks ago with @dominikschubert but I wasn't aware the validation patterns are in the specs 👍
The mandatory fields are easier to generalize than the optional fields. In the "CreateFunction" operation there are only 3
required_membersin the input shape out of 23 members. It often requires service-specific conditionals (sometimes based on service-internal state) to enable these validations.Hence, this might require some service-specific ASF extension because the types in the request handler (i.e., @handler) are not compatible with the validation API (or I need to understand the validation API better) 🤔
As a quick POC: I can retrieve the correct model but it doesn't raise a validation error for the enum value set (would need to investigate inputs API better):
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.
@thrau I discussed with @dominikschubert that we plan to pick up validations in a later polishing step as there are currently more urgent things to finalize.
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.
@thrau I finally gave boto-spec-based validation another quick try with the many Lambda runtime updates slowing us down but it didn't really work:
Nevertheless, I had to abort the idea because the snapshots revealed that the ordering was inconsistent (2 different orders within the Lambda API) and could not be reconstructed using boto-spec-based validation.
I mitigated the problem by re-organizing everything around Lambda runtimes in #9697 to facilitate future updates 🚀