You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Erez Hadad <ER...@il.ibm.com> on 2018/03/04 10:56:14 UTC

Using bash-based actions

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




Re: Using bash-based actions

Posted by Carlos Santana <cs...@gmail.com>.
Yep bash is supported in the current form as I described. 

And will have a dockerskeketon V2 with the new golang Michele is working on 

I envision the new bash to be behind a kind map to the new runtime using the new golang proxy in the CLI

wsk action create fooBash foo.sh —kind bash

Or can be more generic —kind script 

Or we we have a new native

wsk action create foo foo.sh —native2

Something to discuss when we get there 

- Carlos Santana
@csantanapr

> On Mar 4, 2018, at 6:54 PM, Michele Sciabarra <mi...@sciabarra.com> wrote:
> 
> 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 <ER...@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
>>>> 
>>>> 
>>>> 
>>>> 

Re: Using bash-based actions

Posted by Michele Sciabarra <mi...@sciabarra.com>.
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 <ER...@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
> > >
> > >
> > >
> > >

Re: Using bash-based actions

Posted by Michele Sciabarra <mi...@sciabarra.com>.
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 <ER...@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
> >
> >
> >
> >

Re: Using bash-based actions

Posted by Michael Marth <mm...@adobe.com.INVALID>.
Hi Erez,

Fwiw some issues on bash support with more info:
https://github.com/apache/incubator-openwhisk/issues/2927
https://github.com/apache/incubator-openwhisk/pull/3138

Michael



On 04/03/18 13:00, "Carlos Santana" <cs...@gmail.com> 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 <ER...@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
    >
    >
    >
    >
    


Re: Using bash-based actions

Posted by Carlos Santana <cs...@gmail.com>.
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 <ER...@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
>
>
>
>