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 to produce the zip with a single command  running inside the image 
nothing to install


- Carlos Santana

> On Apr 15, 2018, at 2:20 AM, Michele Sciabarra <> 
> 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

Reply via email to