First of all, ngrok is optional. It is not used by default, only if you use 
"--ngrok". See the "how it works" description [1] that talks about the 3 
different "proxy" methods that wskdebug supports today.

Their npm library used in wskdebug has the BSD-2-Clause license (not MIT) [2], 
which should be fine for Apache. Not sure if that optional integration / use of 
their service needs another legal check for ASF?

[1] https://github.com/adobe/wskdebug#how-it-works
[2] https://www.npmjs.com/package/ngrok

Cheers,
Alex
________________________________
From: Carlos Santana <csantan...@gmail.com>
Sent: Friday, February 14, 2020 08:38
To: dev@openwhisk.apache.org <dev@openwhisk.apache.org>
Cc: Alexander Klimetschek <aklim...@adobe.com>
Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request

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