Question on docs - not sure pf provenance - here: ...
# development
Question on docs - not sure pf provenance - here:
This thread: seems to show that our docs for deploying lambdas via docker containers (as opposed to zip uploads) is incorrect. I wanted to see if the author was around and had any idea what was going in here.
In short, our example Dockerfile pretty directly contradicts the docs we link at AWS:
Perhaps those Amazon docs have changed since our docs were introduced?
I didn’t write that, and was only dimly aware that we claimed to support container image lambdas
But if I squint I can sort-of see why what we documented might be expected to work
Well, not actually doing the thing is pretty bad. Best to document only what you know - for sure!
It continues to be a problem that we don't have much expertise in many of the tools Pants supports.
Do we have more information now with which to fix the documentation, based on that thread?
Nope. Clearly? @bland-father-19717 did come extra configuration on the AWS side not detailed in the thread. Someone need to get their hands dirty and simply walk through all this with an AWS account. Even the success we just had was only using the local docker image testing interface, it did not involve actually deploying the lambda to see it worked for real.
Even if we get our hands dirty and do that, we've still sold people short I think. I think you were looking at perf of lambdex and if we really want to give people the idea we have their backs, we should probably be detailing all that. Here's the 4 ways you could go {lambdex / container, unzipped lambdex / container , venv / container, lamdex / zip upload} and here's why you probably want these 2 options.
AFAICT we have no one who knows all this.
Yeah, I was as far along that path as anyone for lambdex zipfile, but never looked at container
I may timebox a couple of hours to look into this properly, particularly the perf issue, which some folks have reported.
That would be great.
Lambdex was a neat shortcut into this area, but I think now it makes more sense to create lambdas with the expected/recommended layout, which I have some reason to think (and will investigate) that AWS leverages for performance hacks
But measurement is everything
So will try some of that
Yeah, that will be good. This takes the magic away: So clearly, we could also provide a
executable. But - no matter what - if the bootstrap has to do any prep before entering its main request processing loop (seeding venvs), that will be a hit whenever the event processor gets rescheduled on a new node.