Hi all,
I am implementing the support for Go actions with a view to extend it to
generic binaries.
So far I settled on a design where I have an executable that basically does the
following:
- read one line in input in json format
- does something with the input then outputs one line in json
- repeat forever
Note in this design the caller writes first. That is not good.
I am testing it in order to detect strange and wrong cases. So far I was able
to distinguish an elf binary and a zip file, and also a non-elf file and handle
properly.
There is however an important case I cannot handle properly: when the binary
exits immediately. For example if you provide a binary without the required
libraries (as it happens with swift binaries). Looks like I have no way to know
if the binary exited until I try to read its output.
So I decided introduce a simple additional requirement: that a binary expected
to work as an openwhisk action will be required to identify itself emitting
some output first, with a single line like this:
{ "openwhisk": 1}
(and I will wait no more than 1 second for that). If I do not get this output I
kill and remove the binary and I restore the preceding one.
It is basically an handshake also providing protocol version informations. I
used a number so in future we may also support binaries speaking a different
protocol, so it is open for future expansions. Also I think it is not an
accident that basically all the protocol in use today starts with an handshake
on the client side. It is the newcomer that needs to identify itself first and
say "hello".
This way I can filter out all many binaries not written properly (since I
basically will remove them and restart the existing one).
Note there is another important case: when a binary receive an input and does
not answer properly. But in such a case, I am leaving to the system to kill the
action when no answer is received within the timeout.
Agreed?
--
Michele Sciabarra
[email protected]
