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
>>> 
>> 

Reply via email to