Michele, this is a useful idea to ease local development. When it's not enough to test using the native runtime (nodejs. python, go) directly, I use the invoke.py script [1] to minic running inside the container.
There was a plugin for the cloud shell from IBM that did what you're suggesting as well and there may be a youtube video for this (@nick mitchell might know where it is, I couldn't find it easily). The thought was to push this even further and instead of replicating the openwhisk API more generally, use a very light weight openwhisk like the one David and Pavel are alluding to. I do think this is a generally useful tool for local development and I think we have several parts to make it possible today. +1 from me. [1] https://github.com/apache/incubator-openwhisk/blob/master/tools/actionProxy/invoke.py -r On Wed, Jul 25, 2018 at 5:17 PM, David Breitgand <[email protected]> wrote: > Hi Michele, > > There is a PR we've submitted on Lean OpenWhisk ( > https://github.com/apache/incubator-openwhisk/pull/3886) > There is also a blog here: > https://medium.com/openwhisk/lean-openwhisk-open-source- > faas-for-edge-computing-fb823c6bbb9b > > Would you like to look at it and see if it will be good enough for what > you want to achieve. > The idea is to have OW (an actual one based on the Controller and Invoker > upstream), but with a very small memory footprint. > > Thanks. > > -- david > > > > > From: Michele Sciabarra <[email protected]> > To: [email protected] > Date: 25/07/2018 08:02 PM > Subject: MiniWhisk: what you think? > > > > Hello, in the process of developing some examples for the goproxy, I > realized I want a tool to make easier developing go actions locally. While > it is generally acceptable to deploy your actions straight to the IBM > Cloud for example when you code in Javascript (or Python) it is less > desiderable for Go because compilation time in the cloud is not so fast as > it is when compiled locally, and you have the additional time of uploading > a binary that is generally bigger than javascript actions. > > SO I ended up with this idea of the "miniwhisk". I am posting here to see > if it is acceptable or... there are better solutions. > > My idea of the miniwhisk is a "single action " executor. It should work > more or less this way: > > $ miniwhisk /path/of/action -runtime openwhisk/actionloop-go-v1.10:master > > -watch *.go -build make -action demo > > This command will launch the runtime > "openwhisk/actionloop-go-v1.10:master" using docker run, then will watch > the files specified with "-w". When a file changes, it will execute the > build command (-build) and then execute and "init" of the action runtime, > post the action to the runtime as an init. > > Additional (and most importantly) it starts a webserver that will listen > to /path/of/action for GET and POST and will then translate requests in > appropriate /run posts for the runtime. > > Basically it is a tool to develop an action in go locally simulating what > would happen when run in the real OpenWhisk. > > > How does sound the idea? Is it worth the effort? > > > > > > > > -- > Michele Sciabarra > [email protected] > > > > > >
