openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Thomas <jthomas...@gmail.com>
Subject Re: Generalising the proposed approach for Go actions to support Generic Binary Actions.
Date Fri, 16 Feb 2018 09:12:01 GMT
Great proposal, looks like a really good solution to the challenges
discussed. Looking foward to seeing this in action.

On 15 February 2018 at 20:20, Michele Sciabarra <openwhisk@sciabarra.com> wrote:
> 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



-- 
Regards,
James Thomas

Mime
View raw message