openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Proposal: offline compilation support for Swift, Go and more...
Date Sun, 15 Apr 2018 14:30:15 GMT
Approach and direction sounds good 

If you read the docs for Swift on how to create a pre-complied binary and zip is the same
process we tell user to use the swift runtime image and use the compile.sh to produce the
zip with a single command  running inside the image nothing to install

[1] https://github.com/apache/incubator-openwhisk/blob/master/docs/actions.md#packaging-an-action-as-a-swift-executable


- Carlos Santana
@csantanapr

> On Apr 15, 2018, at 2:20 AM, Michele Sciabarra <openwhisk@sciabarra.com> wrote:
> 
> 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
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message