openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <>
Subject Implementation plan for Go actions
Date Sat, 24 Feb 2018 18:58:04 GMT
Hello, whiskers

I am at the risk of expanding too much the scope of what I am trying to do, so I want to try
to focus and work step by step.

So  I am writing down my plan for review.

# Step one: implement a good support for GoLang, with piped standard input and output, and
log in stderr.

Because there is not a past support for Go, except the generic docker support, I think I have
some freedom here. 

The support will then work this way (please review carefully):

## /init

The runtime expects posted in /init the usual

 "binary": ...
 "code": ...
 "main": ..

 where "code" is either a zip file (with binary: true) or a source code (with binary: false
or absent).

If it source code, it expects to be a go source.
It places in /action/main/exec.go and compiles it with go build -o /action/exec /action/main/exec.go,
getting a /action/exec to execute.

If is is a zip file, it will unzip it in /action. If there is a /action/exec file in the zip
it will run it. 

If there is not,  it will look if there is a "main" parameter, getting the <main-value>.

It will compile a /action/main/<main-value>.go. If the <main-value> is missing,
it will default to /action/main/exec.go.

Note the zip can include other source files that will be stored in /action/<folders>.
So I will have to use GOPATH=/action to find them.

## /run

The /run behaviour is:

At every request, if no action process is running,it will start one and will pass the first
line as an argument and also in standard output.

If the executable does not terminate, it will keep feeding more input in standard input, expecting
output in standard output (line by line) and logs in stderr. 

The server will have to collect stderr logs and write them in docker stdout, and terminate
the output with the markers when an action completes:


It the executable DOES terminate, it will execute again at the next /run request

## Step 2: need to implement the same  logic for swift actions (we have to keep the existing
compilation infrastructure)

Issues to solve here are the compilation and the "warm" startup problem. I have some ideas
but... I do better to discuss them once the Go support is finished.

## Step 3: will discuss with the list if it is worth to extend the support to the generic
dockerskeleton, that is based on the python proxy.

There are compatibility issues, because the current docker support logs everything in stdout
and the last line is the answer, while for using the pipe you need to do separate log.

How does it sound?
Suggested or required changes?
Am I missing something?

  Michele Sciabarra

View raw message