Re: Preview of a OpenWhisk IDE & Debugger... and an help request

[Alexander Klimetschek]

We can look at it when wskdebug is contributed ... at this point development is 
technically paused since I cannot make changes to it otherwise we'd have to do 
a new grant to Apache, but there is also no openwhisk repo yet to work on it 

But my idea is that action loop should accept some DEBUG_PORT env var that 
would enable debugging and set the debug port in the respective language 
runtime (depends on the language).

That's it. The agents that take care of proxying from remote Openwhisk to local 
container are working independent of the container. It's just how to start the 
container locally in debug mode and with debug port open.

Cheers,
Alex


From: Michele Sciabarra 
Sent: Wednesday, February 12, 2020 06:27
To: Alexander Klimetschek 
Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request

Can you explain how it works and how I can adapt to actionloop? There is some 
documentation in the video but I was unable to read it. I tried to give a look 
at the code but it was not clear.

--
  Michele Sciabarra
  mich...@sciabarra.com



- Original message -
From: Alexander Klimetschek 
To: "mich...@sciabarra.com" , "dev@openwhisk.apache.org" 

Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request
Date: Wednesday, February 12, 2020 2:19 AM

And regarding actionloop specifically: when I looked at it last year, it seemed 
that the generic actionloop container would just need a flag (such as an 
environment variable) to enable debugging, which wskdebug could set 
automatically if it sees an actionloop based kind. Then each specific 
actionloop language container would use this to run the language runtime inside 
the container with debugging enabled and open a debug port, which would also be 
passed through as env var.

Environment variables are good for this, as this makes it impossible to change 
them in a real production Openwhisk environment (as only the openwhisk invoker 
can set these, and they would only have an effect on start of the 
container/app). While wskdebug can easily set these as well.

Cheers,
Alex



From: Alexander Klimetschek 
Sent: Tuesday, February 11, 2020 17:06
To: mich...@sciabarra.com ; dev@openwhisk.apache.org 

Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request

> : 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 
Sent: Tuesday, February 4, 2020 08:18
To: 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 
To: "dev@openwhisk.apache.org" 
Subject: 

Re: Preview of a OpenWhisk IDE & Debugger... and an help request

[Alexander Klimetschek]

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 
Sent: Friday, February 14, 2020 08:38
To: dev@openwhisk.apache.org 
Cc: Alexander Klimetschek 
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  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 
To: "mich...@sciabarra.com" , "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 
*Sent:* Tuesday, February 4, 2020 08:18
*To:* 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 
To: "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 

Re: [Contribution] wskdebug

[Alexander Klimetschek]

Hi David,

I just sent the signed grant to the secretary (cc'ed you).

Great to see that the dependencies are all ok wrt their licenses!

Note that the granted source code zip [1] still has the Adobe copyright 
headers. We would have to remove/replace them. Bertrand told me that I would 
have to do this during the contribution process, I assume when committing this 
(exact) source code to a new openwhisk repo.

Let me know what else I can do! Otherwise I assume I'll have to wait for the 
PMC's vote on the contribution.

[1] https://github.com/adobe/wskdebug/archive/v1.1.2.zip

Cheers,
Alex

From: David P Grove 
Sent: Tuesday, February 18, 2020 06:55
To: dev@openwhisk.apache.org 
Subject: RE: [Contribution] wskdebug


Hi Alex,

Thanks for pushing this forward!

Once the grant is submitted to the ASF secretary we can push ahead
with the formal process.  Thanks for filling in more of the wskdebug.xml; I
updated the version in the incubator svn repository to match.

For the license check, the critical list is the production
dependencies (what is required to run the released module).  Dev
dependencies are not blockers because end users do not need dev
dependencies to use the released software. From your attached list the
production dependency licenses are:

  - MIT: 99
  - ISC: 20
  - Apache-2.0: 8
  - BSD-3-Clause: 3
  - BSD-2-Clause: 3
  - MIT*: 2
  - Custom: http://github.com/substack/node-bufferlist: 1 (effectively MIT)
  - AFLv2.1,BSD: 1
  - Unlicense: 1

MIT, ISC, Apache-2.0, BSD-3-Clause, BSD-2-Clause, Unlicense, are all
"Category A" licenses [1].  All fine.

AFLv3.0 is a "Category A" license.  AFLv2.1 is not listed in any category
at [1]. However, the one package with that license [2] is dual-licensed as
either BSD-3-Clause or AFLv2.1. Since BSD-3 is Category A, we are fine.

So, I see no license issues.  Everything is Category-A.

--dave

[1] http://www.apache.org/legal/resolved.html
[2] https://github.com/kriszyp/json-schema/blob/master/LICENSE

Re: recent openwhisk-runtime-* releases

[Dascalita Dragos]

Ditto. Many thanks Dave !

On Tue, Feb 18, 2020 at 6:51 AM Rodric Rabbah  wrote:

> Thank you Dave for leading the marathon.
>
> -r
>
> > On Feb 18, 2020, at 9:10 AM, David P Grove  wrote:
> >
> > 
> >
> > Thanks to all that have helped with the recent round of releases of our
> > action runtimes!
> >
> > There are now updated releases of OpenWhisk runtimes for NodeJS, Python,
> > Rust, Swift, Ruby, PHP, and Java available at
> > http://openwhisk.apache.org/downloads.html
> >
> > --dave
>

[call for topics] OpenWhisk community call

[Rodric Rabbah]

Hello OpenWhisk community.

I am hosting the Tech Interchange Call tomorrow, Wednesday February 19 at 10am
Eastern. Call on Zoom:

https://zoom.us/my/asfopenwhisk

If you are interested in sharing something you've been working on, have
some questions you'd like to discuss, or want to raise anything else with
the community please let me know by end of your local business day Tuesday.

-r

RE: [Contribution] wskdebug

[David P Grove]

Hi Alex,

Thanks for pushing this forward!

Once the grant is submitted to the ASF secretary we can push ahead
with the formal process.  Thanks for filling in more of the wskdebug.xml; I
updated the version in the incubator svn repository to match.

For the license check, the critical list is the production
dependencies (what is required to run the released module).  Dev
dependencies are not blockers because end users do not need dev
dependencies to use the released software. From your attached list the
production dependency licenses are:

  - MIT: 99
  - ISC: 20
  - Apache-2.0: 8
  - BSD-3-Clause: 3
  - BSD-2-Clause: 3
  - MIT*: 2
  - Custom: http://github.com/substack/node-bufferlist: 1 (effectively MIT)
  - AFLv2.1,BSD: 1
  - Unlicense: 1

MIT, ISC, Apache-2.0, BSD-3-Clause, BSD-2-Clause, Unlicense, are all
"Category A" licenses [1].  All fine.

AFLv3.0 is a "Category A" license.  AFLv2.1 is not listed in any category
at [1]. However, the one package with that license [2] is dual-licensed as
either BSD-3-Clause or AFLv2.1. Since BSD-3 is Category A, we are fine.

So, I see no license issues.  Everything is Category-A.

--dave

[1] http://www.apache.org/legal/resolved.html
[2] https://github.com/kriszyp/json-schema/blob/master/LICENSE

Re: recent openwhisk-runtime-* releases

[Rodric Rabbah]

Thank you Dave for leading the marathon. 

-r

> On Feb 18, 2020, at 9:10 AM, David P Grove  wrote:
> 
> 
> 
> Thanks to all that have helped with the recent round of releases of our
> action runtimes!
> 
> There are now updated releases of OpenWhisk runtimes for NodeJS, Python,
> Rust, Swift, Ruby, PHP, and Java available at
> http://openwhisk.apache.org/downloads.html
> 
> --dave

recent openwhisk-runtime-* releases

[David P Grove]

Thanks to all that have helped with the recent round of releases of our
action runtimes!

There are now updated releases of OpenWhisk runtimes for NodeJS, Python,
Rust, Swift, Ruby, PHP, and Java available at
http://openwhisk.apache.org/downloads.html

--dave

[slack-digest] [2020-02-17] #general

[OpenWhisk Team Slack]

2020-02-17 13:19:29 UTC - Jack Sheehan: Hi guys
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581945569040200

2020-02-17 13:21:16 UTC - Jack Sheehan: I'm using OpenWhisk as part of my 
undergrad research project, and I'm investigating performance differences 
between keeping a pool of pre-warmed containers vs using ML to pre-warm 
containers when needed.

I'm still new to OpenWhisk so haven't quite figured out the ins and outs of it 
all, but the issue I'm facing is when invoking an action it is not using the 
pre-warmed containers, and instead, starting a new prewarmed container. I'm 
sure I'm missing something simple so any help would be great!
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581945676042100

2020-02-17 13:22:09 UTC - Jack Sheehan: I have the manifesto set up correctly I 
think, and my deployment shows pre-warmed containers already there (with more 
popping up when I run my action, i.e. the first action call is cold).
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581945729042900

2020-02-17 15:23:46 UTC - Jack Sheehan: In the below example:

In the manifesto I've set stemCell count to 2, with memory of 256MB as per an 
example on Github which @Rodric Rabbah linked previously.

When I deploy OpenWhisk it starts the 2 Node.js containers and 2 python 
containers. When I create a python action (The example one in the Github - a 
simple hello world), and then invoke it, it creates the 3rd Python container 
and gives it a cold start time of 210ms. So it seems that the pre-warmed 
containers are not being used.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581953026043000

2020-02-17 15:32:33 UTC - Rodric Rabbah: @Jack Sheehan hi, when a stem cell 
container is used (_specialized_) the pool is replenished and another stem cell 
created
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581953553044300

2020-02-17 15:36:02 UTC - Jack Sheehan: Hi, I just figured that out a few 
minutes before you sent the message, though I didn't want to keep spamming the 
chat! I deleted the newest container and realized that the action was still 
returning a warm result, so I figured it had attached to one of the previous 
containers. :slightly_smiling_face:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581953762047100

2020-02-17 15:36:09 UTC - Jack Sheehan: Thanks!
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581953769047300

2020-02-17 15:40:04 UTC - Rodric Rabbah: yw - looking forward to hearing about 
your results
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581954004048000

2020-02-17 16:17:29 UTC - Jack Sheehan: Thanks, I'll be sure to send it into 
the Slack.

Last of the beginner questions for now - should expected pre-warmed container 
'cold' times be around 150-220ms for Python, with expected times of 270-300ms+ 
for a cold start with no pre-warmed containers?

Was running into weird results of 40ms duration for a cold start with no 
pre-warmed container, so I figured I'd messed something up 
:slightly_smiling_face:  A full re-deploy seems to have fixed it and returned 
results in the 300ms region.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581956249050900

2020-02-17 16:19:08 UTC - Rodric Rabbah: which image are you using for python 
action? there is a slow one (where the runtime proxy in the container is using 
flask) and a faster one (where the runtime proxy inside the container is 
implemented in go); the latter is referred to as “action loop”.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581956348052300

2020-02-17 16:20:31 UTC - Rodric Rabbah: you want want to add an annotation on 
the activations - to help you disambiguate the `waitTime` which currently 
doesn’t itemize where an activation waits
there may be some discussion about this from the past but i dont remember well 
enough to point you to it
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581956431053800

2020-02-17 16:43:29 UTC - Justin Halsall: Thanks @Will Plusnick! Yes it works 
for the default namespace which is a CF one (and for some reason I can't find 
in my IBM Cloud profile) so I think you are right and it has to do with IAM. 
Would you be able to submit it to the team? I found this, that was a while ago, 
not sure if it is still relevant? 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581957809053900?thread_ts=1581701740.029400=C3TPCAQG1

2020-02-17 19:21:42 UTC - Rob Allen: is losing track of which votes he’s 
verified and which he hasn’t
grin : Dave Grove
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581967302054200

2020-02-17 19:22:19 UTC - Rob Allen: Now I’m wondering how hard it would be to 
automate parsing the vote emails and their responses and putting on a website
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1581967339054900?thread_ts=1581967339.054900=C3TPCAQG1