openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <openwh...@sciabarra.com>
Subject Generalising the proposed approach for Go actions to support Generic Binary Actions.
Date Thu, 15 Feb 2018 20:20:54 GMT
I spent some time thinking about my proposal to support Go Actions, and I tried to address
some weaknesses that emerged in the discussion (again, thank to James Thomas for pointing
them out).

First, the most relevant, my approach requires you implement a supporting library able to
run an http server in each language you want to support. So one for Swift, one for C/C++ (why
not?), even one for Rust or D or Haskell or whatever. While it is relatively simple, it is
definitely not a generic solution for supporting binaries.

Second, there are some secondary problems: a “race condition”, when I upload an action,
the current server will be  closed so it won’t serve actions. For a very small amount of
time, but it happens. Also I have some concerns about what happens if the user does not upload
a proper executable. It could break the runtime, so some validation is needed.

I hence decided to raise the bar and think to  a better implementation. My updated proposal
is now an extension of the current implementation, but using a pipe and keeping the "child"
process running to serve actions, not terminate and be started again at each request.

Instead of “exec” we should launch a process and pipe input, output and error. The process
however should not be expected (as it is now in Docker actions) to read the standard input,
write some logs then a serialised json objects and then terminate.

Instead, the uploaded binary should be expected to:

* read continuously the standard input line by line
* interpret a single line as a serialised json object
* write logs IN THE STANDARD ERROR
* write the answer in the output as a single line

In this way we can basically use all the compiled languages using just the standard libraries.
It will behaves like a standard command line function. Well, almost (it still will have to
encode and decode json).

A controlling process (of course done in Go) will receive a “/run” request , then it will
feed  to the process, read his answer and then return the answer. 

The implementation is basically an extension of what I already coded in Go (no code to throw
away). It is just a bit more difficult... 

How does this updated proposal sound like?

-- 
  Michele Sciabarra
  openwhisk@sciabarra.com

Mime
View raw message