openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <mich...@sciabarra.com>
Subject Re: Using bash-based actions
Date Sun, 04 Mar 2018 23:54:21 GMT
Hello, I am happy to announce I just implemented also support for "non binaries", i.e. bash
scripts, in my new go-based runtime. Well, it was something in the to-do list actually. If
binary parameter was false in the init request, the runtime returned "scripts not supported".
Now, if binary is false, it will save the "code" and treat it as a script, and it will launch
it in the same way as the others. Nothing fancy, just ordinary linux way of treating scripts
and exe in the same way.
Scripts, even bash ones, however will have to follow a protocol, that currently is:

1. start with a handshake message: { "openwhisk":1}
2. repeat
    2a. read a line in json format
    2b. process the line and emil  a line in json format
    2c. log in stderr

Example:


 #!/bin/bash
 echo '{"openwhisk":1}'
 while true
 do read line
    hello="Hello, $(echo $line | jq -r .name)"
    echo '{"greetings":"'$hello'"}'
 done

-- 
  Michele Sciabarra
  michele@sciabarra.com

On Sun, Mar 4, 2018, at 3:01 PM, Michele Sciabarra wrote:
> I am wondering... would be helpful if you could write bash based actions 
> as a "pipe-loop"? Something reading and writing in stdout like this:
> 
> ----
> #!/bin/bash
> echo '{"openwhisk":1}'
> while true
> do read line
>    hello="Hello, $(echo $line | jq -r .name)"
>    echo '{"greetings":"'$hello'"}'
> done
> ----
> 
> Because I am buiding support for golang and generic binaries, and 
> implementing also support for bash scripts would be as easy as to detect 
> scripts in addition to elf binaries when they are uploaded. 
> 
> The "Start()" command I use should be able to launch also bash scripts....
> 
> -- 
>   Michele Sciabarra
>   michele@sciabarra.com
> 
> On Sun, Mar 4, 2018, at 12:53 PM, Carlos Santana wrote:
> > Hi Herez
> > 
> > Perl and Bash Actions are supported is just that we need to improve the
> > documentation to make it more explicit I’m working on improving docker
> > Actions documentation this week :-)
> > 
> > Try this:
> > 
> > wsk action update fooBash foo.sh —native
> > 
> > Or
> > 
> > wsk action update fooPerl foo.pl —native
> > 
> > It can be any script file the action will chmod +x and then executed.
> > 
> > For the second question I don’t know what you mean for logs.
> > Any text to stdout and stderr before the last line with the json string
> > result are capture in te logs in the activation record
> > 
> > Fell free to open an issue with more info on how to reproduce your problem.
> > 
> > — Carlos
> > PS: my employer is also IBM. :-)
> > 
> > On Sun, Mar 4, 2018 at 5:56 AM Erez Hadad <EREZH@il.ibm.com> wrote:
> > 
> > > Hi folks,
> > >
> > > I'm working with technical people from different organizations outside my
> > > employer (IBM), and we're testing OpenWhisk as a mechanism for integrating
> > > our different tools and services into a single heterogeneous event-driven
> > > programming model.
> > > On the face of it, OW seems like a great fit.
> > > However, when it comes down to implementation, we often hit a case where
> > > the easiest way to delegate action execution to a custom tool is by
> > > writing a simple bash script. This is where things get complicated.
> > > To the best of my understanding (please correct me otherwise), there is no
> > > first-class support for bash runtime in OW.
> > > So, it's down to creating either a "native" action using a zip, or a
> > > custom docker action. Both options are quite more cumbersome than using
> > > native runtimes.
> > >
> > > So this is my first question - would it make sense to have a native bash
> > > runtime in OW? especially given that some of the function that OW
> > > seemingly provides is glue-code between existing tools and services (where
> > > bash also shines).
> > >
> > > As a second issue, we explored the native action. It seems that output is
> > > not captured in the action logs when including ssh calls that invoke bash
> > >
> > > My second question - does anyone have a different experience with this
> > > that they can share? (maybe this problem is not related to OW?)
> > >
> > > Regards,
> > > -- Erez Hadad
> > >
> > > Erez Hadad, PhD
> > > Cloud System Technologies
> > > IBM Research - Haifa
> > > email: erezh@il.ibm.com
> > > phone: +972-4-829-6509
> > >
> > >
> > >
> > >

Mime
View raw message