grav / aws-lumo-cljs-runtime Goto Github PK

View Code? Open in Web Editor NEW

36.0 36.0 1.0 1.45 MB

AWS Lambda Runtime for ClojureScript using Lumo

Clojure 53.69% Shell 42.51% Makefile 3.80%

aws-lumo-cljs-runtime's People

Contributors

Stargazers

Watchers

Forkers

arichiardi

aws-lumo-cljs-runtime's Issues

Use original Lumo repo

The README specifies to use a fork of Lumo, in order to make a static build, but the original Lumo repo as been updated by @arichiardi to support it. We should do this instead and eliminate the need of a fork

Change Dockerfile to build using BUILD_STATIC_BINARY=1 boot release
Update README to reflect this by pointing to the original Lumo repo

Load modules from additional paths

https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders

not authorized to perform: lambda:GetLayerVersion

I have the following issue deploying with runtime 17:

$ npx sls deploy
An error occurred: XXXLambdaFunction - User: arn:aws:iam::xxx:user/yyy is not authorized to perform: lambda:GetLayerVersion on resource: arn:aws:lambda:eu-west-1:313836948343:layer:lumo-runtime:17 (Service: AWSLambdaInternal; Status Code: 403; Error Code: AccessDeniedException; Request ID: zzz).

Replicated issue with versions 9 through 16.

Deploys just fine with version 8: arn:aws:lambda:eu-west-1:313836948343:layer:lumo-runtime:8.

Ran cloudformation with the following permissions for version 17 to no avail:

{
  "Effect": "Allow",
  "Action": "lambda:GetLayerVersion",
  "Resource": "arn:aws:lambda:eu-west-1:313836948343:layer:lumo-runtime:17"
}

Your Environment Information ---------------------------
Operating System: darwin
Node Version: 12.1.0
Serverless Version: 1.49.0
Enterprise Plugin Version: 1.3.6
Platform SDK Version: 2.1.0

Load dependencies dynamically

Current limitations

The current runtime does not support loading dependencies in any way. But it is possible to load e.g. Promesa by adding the promesa jar to the function zip, and updating the bootstrap file to something like :

$bin_path/lumo --classpath .:/opt:promesa-2.0.1.jar ...

That said, it would be nice to be able to dynamically load dependencies (like NodeJS enables you to load whatever's in node_modules) without having to hack the runtime every time.

Hence, a suggestion

Lumo can load dependencies dynamically using the lumo.classpath/add! api. Maybe we could make a convention where a deps.cljs file is loaded on bootup, which in turn loads all necessary dependencies using the aforementioned api? Like so:

bootstrap supplied in the runtime:

...
$bin_path/lumo --classpath .:/opt --init deps.cljs  ...

deps.cljs (or something similar) supplied in the lambda function zip:

(require '[lumo.classpath :as cp])
(cp/add! "promesa-2.0.1.jar")
(cp/add! "....jar") 
...

... or the user could specify the dependencies in a text file, which the runtime would parse and load in a doseq ... lots of possibilities for a convention.

Bad error reporting

Hi there!

I was playing around with this project and I got the following errors in CloudWatch, kind of all of a sudden, after I saw it working a couple of times:

(node:12) UnhandledPromiseRejectionWarning: Error: Assert failed: Unexpected http://127.0.0.1:9001/2018-06-01/runtime/invocation/d9a9675a-0ac2-47ef-aab3-f142775739a7/errorresponse:
{
    "meta": null,
    "cnt": 3,
    "arr": [
        {
            "ns": null,
            "name": "body",
            "fqn": "body",
            "_hash": -2049205669,
            "cljs$lang$protocol_mask$partition0$": 2153775105,
            "cljs$lang$protocol_mask$partition1$": 4096
        },
        "",
        {
            "ns": null,
            "name": "status",
            "fqn": "status",
            "_hash": -1997798413,
            "cljs$lang$protocol_mask$partition0$": 2153775105,
            "cljs$lang$protocol_mask$partition1$": 4096
        },
        405,
        {
            "ns": null,
            "name": "headers",
            "fqn": "headers",
            "_hash": -835030129,
            "cljs$lang$protocol_mask$partition0$": 2153775105,
            "cljs$lang$protocol_mask$partition1$": 4096
        },
        {
            "meta": null,
            "cnt": 3,
            "arr": [
                "date",
                "Wed, 17 Apr 2019 00:18:17 GMT",
                "content-length",
                "0",
                "connection",
                "close"
            ],
            "__hash": null,
            "cljs$lang$protocol_mask$partition0$": 16647951,
            "cljs$lang$protocol_mask$partition1$": 139268
        }
    ],
    "__hash": null,
    "cljs$lang$protocol_mask$partition0$": 16647951,
    "cljs$lang$protocol_mask$partition1$": 139268
}
(= status 200)
at /tmp/tmp.mn6GxQr1qo:68:8
at process._tickCallback (internal/process/next_tick.js:68:7)
(node:12) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:12) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I see there is a status 405 in there? What can be the cause?

This also made me realize that the trade-off of a custom layer is that you don't have visibility of these kind of things when they happen.

Nonetheless, thank you very much, this was very great to try out!

The lumo runtime does not read from node_modules

Hi again!

So the problem is that when I include node modules in my lamdba function, the runtime cannot find them.

For instance I get:

Cannot find module 'ajv'
	 Function.Module._resolveFilename (internal/modules/cjs/loader.cljs:655:15)
	 Function.Module._load (internal/modules/cjs/loader.cljs:580:25)
	 Module.require (internal/modules/cjs/loader.cljs:711:19)
	 require (internal/modules/cjs/helpers.cljs:14:16)
	 Object.<anonymous> (/tmp/tmp.0BjCyWLnRv/test.cljs:2:24)
	 Module._compile (internal/modules/cjs/loader.cljs:805:30)
	 (Object.It)
	 (Object.lumo.repl.caching_node_eval)
	 (NO_SOURCE_FILE <embedded>:6030:9)
	 z (NO_SOURCE_FILE <embedded>:6031:22)

Let me try to explain the problem: because the bootstrap binary executes a file like

lumo /tmp/tmp.0BjCyWLnRr

It seems like node_modules is not read by lumo there.

This could be a lumo issue (or not) but it will require a change of the bootstrap script and maybe runtime.cljs.

Static lumo crashes

Hi 😁

This is not really an issue of this project but I figured I could open just to get some feedback

I tried to compile lumo statically on my machine and it seemed to work fine until I started trying the aws-sdk, which unfortunately results in a segmentation fault.

I then tried to launch the Amazon ami they recommend for compiling lamdba runtimes and tried to compile lumo there statically.
Unfortunately this time I could not even get a binary...it seems node compilation reports some C++ error I don't even want to look at 😁

My question would be, have you used the SDK against your binary by any chance? Was it working?

Can try that tomorrow as well.

grav / aws-lumo-cljs-runtime Goto Github PK

aws-lumo-cljs-runtime's People

Contributors

Stargazers

Watchers

Forkers

aws-lumo-cljs-runtime's Issues

Use original Lumo repo

Load modules from additional paths

not authorized to perform: lambda:GetLayerVersion

Load dependencies dynamically

Current limitations

Hence, a suggestion

Bad error reporting

The lumo runtime does not read from node_modules

Static lumo crashes

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent