Legal questions about licensing can be submitted to the LEGAL Jira project by the way.
On Fri, Feb 14, 2020 at 09:33 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 > > > > > > -- Matt Sicker <boa...@gmail.com>
