openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <mich...@sciabarra.com>
Subject Re: [LONG] Discussing my implementation of Go actions
Date Fri, 09 Mar 2018 13:43:44 GMT


On Fri, Mar 9, 2018, at 12:37 PM, Carlos Santana wrote:
> Thank you Michele for the contribution.
> I already provided some initial feedback in the PR
> 
> https://github.com/apache/incubator-openwhisk-runtime-go/pull/1

Yes I see you asked to remove the handshake()

As I told you, an eventually crashing exec will be detectable only at the first  /run.

I am still convinced I should instead be detected at /init time.

I still hope to find a way to remove the handshake AND not wait until /run to detect a wrong
exec.

Of course if I do not find a solution will settle for removing the handshake()
 
> 
> On Fri, Mar 9, 2018 at 6:13 AM Michele Sciabarra <openwhisk@sciabarra.com>
> wrote:
> 
> > I just did a  PR of my version of the Golang action implementation. It
> > does some "breaking" changes  and there is some discussion on the slack
> > channel.
> >
> > So I report the current situation n here, looking for advices and change
> > recommendations.  Since I am a bit confused, if I remember well, one Apache
> > rule is  the mailing list is the ultimate source for the truth...
> >
> > It currently works this way (I call it the "pipe-loop" protocol)
> >
> > A golang action (or a generic binary) is expected to follow this
> > "protocol":
> >
> > * starts with  {"openwhisk": 1}
> > * reads on line in stardard input, expecting a json ON A SINGLE LINE
> > * process the line, emits logs in stderr (can be multiple lines)
> > * outputs a line in stdout in json format ON A SINGLE LINE
> > * repeat forever
> >
> > It is important to note this design is easy to implement and works even
> > for bash scripts, but it is easy to use also perl, ruby, haskell in an
> > EFFICIENT way.  Indeed this bash script (with jq) is part of my tests:
> >
> > ---
> > #!/bin/bash
> > echo '{"openwhisk":1}'
> > while read line
> > do
> >    name="$(echo $line | jq -r .name)"
> >    logger -s "name=$name"
> >    hello="Hello, $name"
> >    logger -s "sent response"
> >    echo '{"hello":"'$hello'"}'
> > done
> > ---
> >
> > Things discussed:
> >
> > 1) ​remove the header {"openwhisk":1}
> >
> > Actually initially it was not there. But I decided to add this
> > requirements because the action need to speak a protocol ANYWAY.
> >
> > Most important, I explain why I require it starts with "{"openwhisk: 1}".
> >
> > The main reason is: I start the child process at init time, and I wanted
> > to detect when it does not behave properly.
> >
> > The simplest problem happens when the action crashes immediately. For
> > example, a common reason for this problem is uploading a binary using some
> > dynamic libraries not available in the runtime. For  example a swift
> > action. By defaults it load a lot of different libraries, it crashes
> > immediately but I cannot detect it until I try to read its stdin.
> >
> > I can remove this requirement if someone can show me the go code to check
> > that cmd.Start("true") or cmd.Start("pwd") exited 😃
> >
> > If it is not doable, and I skip  the handshake, even if the command
> > crashed, I will not detect the problem until a /run is executed and the
> > action times out...
> >
> > Carlos say it is fine. It is ok for me but I still think an early problem
> > detection would be better. Also James recommended me to provide as much as
> > error detection to the user as early as possible. Kinda of conflicting
> > directives here...
> >
> > Suggestions?
> >
> > 2) more checks at init time
> >
> > I added some sanity checks.  Probably too many. I tried to detect the
> > error at deployment time, not at invocation time.
> >
> > This is different from what currently for example dockerskeleton does.
> >
> > If I upload for example something wrong, like a non-zip, a non-elf
> > executable, my init returns {"error": "description"}, while currently the
> > dockerskeleton returns always OK.
> >
> > Recommendations here?
> >
> > 3) output to another channel the result
> >
> > Currently I require logs goes to stderr, and stdout is for interacting
> > with the parent process.
> >
> > Rodric suggested to output to a separate channel (channel 3?)  and use
> > stdout and stderr for logs.
> >
> > While doable, I need to provision another pipe, and the implementation
> > should probably do some syscalls to retrieve file descriptor 3. It would
> > complicate implementation, while currently it is straightforward for any
> > language that does not have a library available. For swift, even to flush
> > stdout I needed to write "linux specific" code... I do not dare to think
> > what I need to do to write in fd3...
> >
> > My opinion is that using stdout for I/O and stderr for logs is a better
> > choice than opening another file descriptor.
> >
> > Thoughts here?
> >
> >
> >
> >
> >
> >
> >
> > --
> >   Michele Sciabarra
> >   openwhisk@sciabarra.com
> >

Mime
View raw message