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 <openwh...@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
>  openwh...@sciabarra.com

Reply via email to