openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <openwh...@sciabarra.com>
Subject Proposal: offline compilation support for Swift, Go and more...
Date Sun, 15 Apr 2018 06:20:03 GMT
A brief recap: I implemented support for Golang actions, and adapted support to work also with
Swift, using another "high performance" protocol. The support actually works for any binary
that follow a certain "protocol", so it could be used for programs written in c, rust, haskell,
whatever.

For convenience the proxy also supports zip and sources. Source support works compiling an
action on the fly, thus producing a binary when you init a runtime. Source support is language
specific, so I have now an image able to compile golang actions and another able to compile
swift actions. More can be provided (and it would be interesting to do).

All of this has been already coded and tested, I submitted the PR waiting for review. 

Now my proposal. Source support has a problem: slow initialization. Source support is very
convenient in development but  when the application scale, re-initializing more runtimes using
source is slow. So you have a warm-up problem. 

This problem can be solved precompiling the images but it was considered a complex problem
to solve. Except I realized is not! Having built source support in the runtimes, it is a small
step to adapt the runtimes to became also offline compilers!

Most notably my idea is this: assuming you have the sources in  folder  like ./src, you can
generate the executable using something like:

$ docker run -v $PWD/src:/src -v $PWD/out:/out  actionloop-golang compile main.go main

Translated:
1. run the runtime as a compiler invoking a 'compile' in the image
2. pass the source and the target folder as volumes to the image
3. run the compilation (compile will expect sources to be in /src and place the final executable
in /out)

This way you will be able to generate the binaries offline without having to do a complex
setup. 
Then you can deploy the binary with

$ wsk action create myaction out/main --native

Processing sources for generating binaries can be done by some processing tools, at some point
can be even integrated in wskdeploy or provided by some preprocessing. That is not the biggest
problem, once you have support in place on the runtimes.

If you agree on this proposal I can go on implementing AND DOCUMENTING them for the images
I am building, the go image and the swift image. 

Thoughts?


-- 
  Michele Sciabarra
  openwhisk@sciabarra.com

Mime
View raw message