About ngrok I have being using inlets as an alternative to ngrok and the license is MIT which is good one.
https://github.com/inlets/inlets - Carlos Santana @csantanapr > On Feb 14, 2020, at 10:33 AM, Michele Sciabarra <mich...@sciabarra.com> wrote: > > Yes I have a big advantage, in the fact I control the proxy. > I read your documentation and from what I see it works in a very similar way: > you "decorate" the action with your own action, while I am actually working > at the proxy level. But for the rest the concept is similar: create a tunnel > to reach the action, whenever it is. > > I started to dissect the code, and I noticed you use ngrok for creating a > tunnel. I am trying to understand what it is exactly, but is this? > https://ngrok.com/ > > What is the license state? It looks like to be proprietary code coupled with > a proprietary service that happens to have a free (as a beer) but not open > source version. Is it correct? Is it appropriate/acceptable for an apache > project? > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > ----- Original message ----- > From: Alexander Klimetschek <aklim...@adobe.com> > To: "mich...@sciabarra.com" <mich...@sciabarra.com>, > "dev@openwhisk.apache.org" <dev@openwhisk.apache.org> > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > Date: Wednesday, February 12, 2020 2:06 AM > >> : Standalone OpenWhisk running in a docker container, because the debugger >> (and the IDE) runs in another docker container. > > I guess this isn't really a scenario that wskdebug is built for, because in > this case you have full control over what happens in that local openwhisk and > debug ports of action containers can be visible in your host. IIUC this might > be what you are doing already - not sure I fully grasped that however. > > wskdebug is generally meant for debugging when you are using a remote > Openwhisk (say IBM Cloud or Adobe I/O Runtime) and you have no other choice. > Many/most action developers will not themselves be able to spin up a local > openwhisk, and sometimes you really need to debug in the real environment, > not a local copy. > > But ignoring that, I wonder what exactly is failing when you run wskdebug > inside a container? In theory it should be feasible. Might be something that > can be fixed. > > Cheers, > Alex > > > *From:* Michele Sciabarra <mich...@sciabarra.com> > *Sent:* Tuesday, February 4, 2020 08:18 > *To:* dev@openwhisk.apache.org <dev@openwhisk.apache.org> > *Subject:* Re: Preview of a OpenWhisk IDE & Debugger... and an help request > > The main reason because I tried my own approach instead of using wskdebug, > that I tried, is because I was unable to make it work from within a docker > container. > > My setup is: Standalone OpenWhisk running in a docker container, because the > debugger (and the IDE) runs in another docker container. > > I need this setup because I want to provide a very simple installation, a > wskide command that will setup the development environment. If I run the > debugger from the standalone openwhisk works. But I have problems to add also > the IDE that requires also node. So the prerequisites to run the whole thing > would be a java of a given version, a node of the right version and docker. > > So I decided to go for a full dockerized solution. I have a launcher, written > in go, that starts standalone openwhisk running in a docker container, and > another container with the debugger and the editor (theia). In this setup, > wskdebug does not work. It tries to do something with docker and does not > work. I was unable to understand what is wrong, I tried to read the code but > I do not follow it. > > For this reason I simply put an action in debug mode (using the runtime) and > then I connected from the ide. It is more straightforward. There are still > some issues to sync. But everything is open for discussion, I am more than > happy if I can re-use wskdebug. > > -- > Michele Sciabarra > mich...@sciabarra.com > > ----- Original message ----- > From: Alexander Klimetschek <aklim...@adobe.com.INVALID> > To: "dev@openwhisk.apache.org" <dev@openwhisk.apache.org> > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > Date: Tuesday, February 04, 2020 5:02 PM > > Hi Michele, > > please note that wskdebug [1] is a debugger for any kind. Nodejs has the best > out of the box support since that’s what we are exclusively using right now. > Other languages can already be supported using the right command line > arguments (ports, docker command etc), which is how Java worked. Given this > new __OW_DEBUG_PORT env variable, it can be set with wskdebug using > —dockerArgs. Contributions are welcome to make this more automatic based on > the kind/image version of the action :-) > > FYI, On the contribution front, I will work on the legal documents this or > next week. > > [1] https://github.com/adobe/wskdebug > > Cheers, > Alex > ________________________________ > Von: Michele Sciabarra <mich...@sciabarra.com> > Gesendet: Monday, February 3, 2020 2:27:15 AM > An: dev@openwhisk.apache.org <dev@openwhisk.apache.org> > Betreff: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > > This is basically also what I am trying to do. > > I guess the difference is that you are doing this using the standard nodejs > runtime while I am doing the same using the goproxy. I am sure it is also > similar to the adobe/wskdebug that I tried to use, and works but it specific > to the node and java runtimes, without actionloop. > > My goal is to get the debugger for the "other" languages, most notabily > typescript python and go. > > Let's discuss on the call to see how we can align efforts. > > > -- > Michele Sciabarra > mich...@sciabarra.com > > ----- Original message ----- > From: Dominic Kim <style9...@gmail.com> > To: dev@openwhisk.apache.org > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > Date: Monday, February 03, 2020 10:52 AM > > Thank you for the details. > It seems what you are tying now is similar with our approach and can be > aligned with ours too as it is generic like you said. > > We enabled the debugging of Nodejs runtime with chrome DevTools protocol > https://chromedevtools.github.io/devtools-protocol/. > Our UI communicates with the real remote OW deployment. > We implemented one proxy server to correlate a debugging session with a > corresponding action container. > Since each action container is not exposed to public, we also have a bridge > component on each invoker machine for location transparency. > > If I understood correctly, each container will connect to the IDE in a > reverse way in your version and similarly it connects to the proxy via > bridge in our version. > SoI think two versions can coexist, if we make the interface extensible. > > Maybe I can share more details at this interchange call. > > > Thanks > Best regards > Dominic. > > > > > 2020년 2월 3일 (월) 오후 4:47, Michele Sciabarra <mich...@sciabarra.com>님이 작성: > >> Hi Dominic >> >> the preliminary work I did was already submitted as a PR to build a >> standalone docker image (that is critical for my design). >> >> The rest the work is here: https://github.com/sciabarracom/openwhisk-ide >> and uses the (upcoming) typescript runtime here >> https://github.com/sciabarracom/openwhisk-runtime-typescript. But do not >> use it yet as it is pretty much work in progress, no documentation nor it >> is even remotely stable. >> >> The key idea is to leverage the fact that actionloop launches a process >> for each action, and I am simplying putting the process in debug mode. Then >> I am using Eclipse Theia, that is vscode in a browser, >> https://theia-ide.org/ as an editor and debugger interface. >> >> The key problem I have is to connect the action running under a debugger >> (problem solved) with the debugger client. So far I am just starting the >> action , asking to the action its IP and then connecting to it with the >> debugger. Problem is that the action may have a different IP >> >> I am now in the process of trying a different approach, where I >> communicate to the action the IP of the IDE and ask to the action to >> connect back, maybe creating a tunnel. In this way it could work in a more >> generic way, even with a production whisk, as the only requirement will be >> to have the client (that is itself a docker container) reachable by the >> action. >> >> -- >> Michele Sciabarra >> mich...@sciabarra.com >> >> ----- Original message ----- >> From: Dominic Kim <style9...@gmail.com> >> To: dev@openwhisk.apache.org >> Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request >> Date: Monday, February 03, 2020 7:07 AM >> >> Hi Michele. >> Thank you for sharing great works. >> >> We here(Naver) are also using a web based debugging feature and I would >> like to align ours with yours. >> Is there any reference that I can follow up your works? >> Did you open any PR? >> >> And I want to share our version at this tech interchange call. >> >> >> Best regards >> Dominic >> >> >> 2020년 2월 2일 (일) 오전 7:02, Michele Sciabarra <mich...@sciabarra.com>님이 작성: >> >>> Great suggestion. I know how to pass configuration parameters, what is >> the >>> configuration to set? >>> >>> -- >>> Michele Sciabarra >>> mich...@sciabarra.com >>> >>> ----- Original message ----- >>> From: Rodric Rabbah <rod...@gmail.com> >>> To: dev@openwhisk.apache.org >>> Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request >>> Date: Saturday, February 01, 2020 8:35 PM >>> >>>> The first problem is that I need to invoke an action twice as the first >>> time the debugger does not attach. I guess it is because the image is >>> paused. >>> >>> Did you try to change the pause grace configuration to an max int. >>> >>> -r >>> >>