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 <[email protected]> > 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 > [email protected]
