Re: runtime images tagged "master" vs "latest"
> So far runtimes updates are very slow traffic and have not need this small > window so far, so maybe we can leave it as "latest" is bleeding edge. That’s my preference also. One less tag and avoids confusion. So “latest” and explicit tags corresponding with change logs. -r
Re: MiniWhisk: what you think?
Indeed after thinking about my idea was to try to extend the invoker.py to serve urls, and add a —watch feature so if files are modified then they are zipped and sent to the runtime as /init. Since the go runtime compiles already I think it is better to leave the compilation to the runtime. Another interesting feature of the goproxy is that it supports the “unnecessary” multiple initializations so it should ne able to do incremental compilation at least for go code.Another interesting feature that I am ‘stealing’ from the openwhisk shell is support for debuggers. I will try to make available delve if I can. I suppose it is just enough to be able to run the client executable with delve and expose the debugger port. I think the openwhisk shell is awesome for node but I want something specific for go that works with vscode, and let me run tests on the code as I develop it. And also the go debugger now.I plan to write the miniwhisk for now in Python, as part of the examples for go. Then eventually rewrite it in go if it proves interesting enough to became a standalone tool. Thoughts? -- Michele Sciabarra mich...@sciabarra.com On Thu, Jul 26, 2018, at 8:54 PM, Rodric Rabbah wrote: > > > My approach was to implement the OpenWhisk platform API > > using a stub server that would execute the actions using Docker in > > the host> > system. > > You really don’t need this though - look at the invoker.py > script. That> is enough IMO, either extending that or copying that into a new > executable (go or node). > > -r
Re: MiniWhisk: what you think?
> My approach was to implement the OpenWhisk platform API > using a stub server that would execute the actions using Docker in the host > system. You really don’t need this though - look at the invoker.py script. That is enough IMO, either extending that or copying that into a new executable (go or node). -r
Re: MiniWhisk: what you think?
Share the code and let’s collaborate. If you remember I started the Openwhisk runtime from your code, there are still a few lines of code left :) -- Michele Sciabarra mich...@sciabarra.com On Thu, Jul 26, 2018, at 7:38 PM, James Thomas wrote: > Michele, > > I'd also started a project this month called "miniwsk" around local > development - great minds! :) > > I had a similar idea about an instance of the platform that > would spin up> containers locally. My approach was to implement the OpenWhisk > platform API> using a stub server that would execute the actions using Docker > in > the host> system. I also wanted to use Go lang for the mock server so that > it would> be a simple binary I could start on demand. Implementing the > API means I> can just use all the normal OpenWhisk tools without modification > by > pointing them to localhost. > > It's still in the super-early stages of development so I'm not > sure when> I'll have it ready for publishing... I wasn't going to handle re- > build go> based stuff as your idea does. It was purely a stub server to invoke > containers on demand. > > On 25 July 2018 at 15:56, Michele Sciabarra > wrote:> > > 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 > > openwh...@sciabarra.com > > > > > > -- > Regards, > James Thomas
Re: MiniWhisk: what you think?
Michele, I'd also started a project this month called "miniwsk" around local development - great minds! :) I had a similar idea about an instance of the platform that would spin up containers locally. My approach was to implement the OpenWhisk platform API using a stub server that would execute the actions using Docker in the host system. I also wanted to use Go lang for the mock server so that it would be a simple binary I could start on demand. Implementing the API means I can just use all the normal OpenWhisk tools without modification by pointing them to localhost. It's still in the super-early stages of development so I'm not sure when I'll have it ready for publishing... I wasn't going to handle re-build go based stuff as your idea does. It was purely a stub server to invoke containers on demand. On 25 July 2018 at 15:56, Michele Sciabarra wrote: > 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 > openwh...@sciabarra.com > -- Regards, James Thomas
