This PR corresponds to issue #4733. Not sure how to link it

note: running integration tests locally fails, but it seems that it was failing before my changes

Thanks for this PR @isaac-j-miller ! 👍 We'll have to run a couple of checks to see how this will impact various parts of the Lambda execution in LocalStack. So, I'd expect that we'll need a few iterations for this change, but certainly a great starting point.

To kick things off - can you please push another small commit to your branch, to re-trigger the CI builds (apparently the build was not triggered by Github). Thanks!

Thanks! I figured that there would have to be a couple iterations on this because I'm not super familiar with the patterns, etc. that are used in localstack, or whether it would make sense to instead make the amazon repository the default instead of lambdaci

Sorry @isaac-j-miller , the CI build was again not triggered for the latest commit. This is really annoying - seems to be a Github issue (we've recently also seen this with a few other (but not all) user accounts in the past).

Not sure how to solve this - perhaps you could get in touch with customer support? We have already provided permission to execute builds for your user account in this repo, but it's still not working. If worse comes to worst, we can also take your commits and create a separate PR (making sure that your authorship will be retained..). Thanks!

On my end, it says that for a first time contributor, an admin has to
approve CI builds

@isaac-j-miller We did that, actually. Can you please give me push access to your fork/branch? Perhaps it helps if I push a dummy commit to your branch.. Thanks

Done! Builds running now.. Actually, I had to do a git rebase master and resolve a few minor merge conflicts to get the latest version. Hope you won't run into merge conflicts when pulling the branch (otherwise checking out a fresh copy of the branch may help). Thanks

Ok great @isaac-j-miller , looks like the build was triggered this time. 👍 https://app.circleci.com/pipelines/github/localstack/localstack/2070/workflows/78be3800-04f9-4a53-8823-d54d507628c5/jobs/7682

There's a few minor issues with the code linter - can you please take a look? You can replicate this via make lint (or make format to auto-correct the formatting). Thanks

Actually - @isaac-j-miller we'd be happy to take over the PR from here and get it over the line - what are your thoughts on that? Might be a bit easier than the review/update cycles on the PR (as I mentioned, this is a fairly involved change, and I'd expect that we'll need quite a few iterations).

We'd squash your existing commits into a single one (to make sure that your authorship is retained) and then branch off a new PR to make any required changes for the integration. Please let us know if that works for you. Thanks!

@whummer that sounds good

Please review this @whummer so I can get python3.9 support from localstack.

Please review this @whummer so I can get python3.9 support from localstack.

It's kind of a shameless plug, but if you want to use Python 3.9 or Node.js 14.x images in Localstack without waiting for official images to be supported, you can use my fork of the LambCI repo with all the latest runtimes (both x86 and arm64). 🙈

Simply pass the following env var to the LS container:

LAMBDA_CONTAINER_REGISTRY=mlupin/docker-lambda

Thanks @mLupine ! We have temporarily introduced a small change in 3b52abf that enables using the mlupin/docker-lambda image for the python3.9 runtime, until we've made the switch to the official AWS images.. 👍 Thanks!

Where is this PR at?

Thanks @navels , apologies for the delay on this one - we are still in the process of spec'ing out the solution that most suitably fits the internals of our Lambda implementation. Ultimately, I think we'd want to get the official AWS images integrated into LocalStack (even though the work by @mLupine on arm64 support for lambdci is awesome! 🙏 ). ARM64 support will be critical, as we've recently released multi-arch builds to support, e.g., Apple M1.

The main question we are evaluating is whether we want to rely (1) solely on the "over-the-network" invocations required by the AWS Lambda Runtime Interface Client (RIC), or (2) also enable the Docker "entrypoint-based" invocations that Lambci has introduced (i.e., starting up an emphemeral Lambda container that serves only a single request).

For (1), we could build upon our learnings from the "stay-open" invocation mode for the docker-reuse Lambda executor that was recently merged.

For (2), the advantage is that all communication is only happening in the local context of the Lambda container (the event payload being passed in via stdin or as an environment variable to the container) and does not rely on connectivity between the LocalStack container and the Lambda container.

(Arguably, we could prescribe that proper connectivity between LocalStack and the Lambda containers is a requirement, but we're seeing a lot of users who are struggling with the networking setup in docker/docker-compose (or even with Helm/Kubernetes) - hence the "entrypoint-based" invocations do actually provide some benefit. From an initial analysis, it seems that we should be able to get the "entrypoint-based" invocations working with the official AWS images as well - but we'll see..)

We'll prioritize this work item and will provide an update in the next couple of days.. Thanks!

With Nodejs 16.x hopefully coming soon, has there been any movement on switching off of lambci?

Also, with the throttling changes that have been made to DockerHub, would it be possible to use the public ECR versions? https://gallery.ecr.aws/lambda/

Any updates to share?

Hi there! We are definitely working on it! We are trying to do it right, but this might take a couple more weeks. Stay tuned for more updates soon!

Hi, any update on this?

Yes, I can provide you with an update. We have a prototype of a new lambda engine already merged (see #5306 ). It is based on the official AWS images and shows a huge performance improvements (cold invocation times of around 400-600 ms, hot invocation of around 5ms for simple lambdas, like an echo). Its already merged to master, and can be activated by the instructions in the PR.
However, since we want to make it right, currently there are efforts regarding testing to enable better parity. Therefore, its only a prototype, basically only create / invoke / delete works, as of now. Also, no integrations with other services. and we only tested python and node as of now. Still, we want this to change soon and get traction, once we are done with the work on the tests.

Hi! As explained in my former post, this is now part of a complete Lambda rework. Just exchanging the images will not work like this, but needs more work behind it (see #5306 for our approach to this).
The rework is not abandoned, but temporarily postponed, since other aspects took precedence now.
I will now close this PR. As long as we are not promoting the new provider to default, we will continue supporting new managed runtimes were possible with the docker lambda images of @mLupine (or our own, where necessary), as they integrate seemlessly into the current provider.
Once the work on the new one is finished, we will use the official images like requested.

Still, I want to thank you for your contribution (which also kickstarted the lambda project), they are always very welcome!