Conversation
3528708 to
2466dc9
Compare
2466dc9 to
4ff6d5c
Compare
4ff6d5c to
6a1608a
Compare
6a1608a to
ad2dded
Compare
| 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") |
There was a problem hiding this comment.
re-enable as soon as the new Docker image is on DockerHub.
Bumping the docker Python dependency requires a synchronized update of LS, ext, and the Docker image on DockerHub. The current CLI tests use the latest image from DockerHub.
The update of docker adds a new platform flag and running this test against an old localstack image yields the error TypeError: run() got an unexpected keyword argument 'platform' (not visible in CI). Locally building a new LS Docker image via make docker-build fixes the issue.
dominikschubert
left a comment
There was a problem hiding this comment.
LGTM! Awesome work, very clean and well documented 🚀
| ) | ||
| return os.environ.get("TEST_TARGET") != "AWS_CLOUD" and os.environ.get( | ||
| "PROVIDER_OVERRIDE_LAMBDA" | ||
| ) not in ["asf", "v2"] |
| if architectures: | ||
| if len(architectures) != 1: | ||
| raise ValidationException( | ||
| f"1 validation error detected: Value '[{', '.join(architectures)}]' at 'architectures' failed to " | ||
| f"satisfy constraint: Member must have length less than or equal to 1", | ||
| ) | ||
| if architectures[0] not in [Architecture.x86_64, Architecture.arm64]: | ||
| raise ValidationException( | ||
| f"1 validation error detected: Value '[{', '.join(architectures)}]' at 'architectures' failed to " | ||
| f"satisfy constraint: Member must satisfy constraint: [Member must satisfy enum value set: " | ||
| f"[x86_64, arm64], Member must not be null]", | ||
| ) |
There was a problem hiding this comment.
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.
(please not in this PR though 😁 )
There was a problem hiding this comment.
@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.
that should definitely go into ASF :-)
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.
@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_members in 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):
service = load_service("lambda")
operation = service.operation_model("CreateFunction")
shape = operation.input_shape.members["Architectures"].member
invalid_architecture = "x42"
validation_errors = ParamValidator().validate(invalid_architecture, shape)
There was a problem hiding this comment.
@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.
@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:
from localstack.aws.protocol.validate import ParamValidator
from localstack.aws.spec import load_service
service = load_service("lambda")
operation = service.operation_model("CreateFunction")
shape = operation.input_shape.members["Runtime"]
invalid_runtime = "python3.10777"
validation_errors = ParamValidator().validate(invalid_runtime, shape)
print(str(validation_errors))
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 🚀
Tested locally through `make docker-build`
ad2dded to
9e8516d
Compare
This PR adds support for additional Docker flags and fixes ARM issues with lambda.
Changes
v2) in lambda testsAddresses
LAMBDA_DOCKER_FLAGS=--user nobodyRelated Issues
Follow Up
tests.bootstrap.test_cli.TestCliContainerLifecycle.test_start_cli_within_containeras soon as the new localstack image is on DockerHub (see comment here)