[slack-digest] [2019-02-20] #wskdeploy

[OpenWhisk Team Slack]

2019-02-20 13:19:33 UTC - Thomas Peikert: it's currently not possible to 
specify default as a runtime version. this only leads to failures for zips, as 
default is automatically used when inferring from file ending...

I added some tests to verify this: 
 but I have 
too little understanding of the platform as to work on a fix. anyone interested 
in helping with that?^^
https://openwhisk-team.slack.com/archives/C79ALSWJJ/p1550668773001700

2019-02-20 15:51:15 UTC - Carlos Santana: I think you should be able to specify 
runtime `nodejs:default` as the kind
https://openwhisk-team.slack.com/archives/C79ALSWJJ/p1550677875002200

2019-02-20 15:51:24 UTC - Carlos Santana: or `swift:default` and so on
https://openwhisk-team.slack.com/archives/C79ALSWJJ/p1550677884002500

2019-02-20 15:51:42 UTC - Carlos Santana: if not then there is a bug @Matt 
Rutkowski @Mark Deuser ^^
https://openwhisk-team.slack.com/archives/C79ALSWJJ/p1550677902002800

[slack-digest] [2019-02-20] #kubernetes

[OpenWhisk Team Slack]

2019-02-20 15:00:23 UTC - Slackbot: Reminder: Web Meeting: Tech Interchange 
(bi-weekly): 
* Day-Time: Wednesdays, 11AM EST (Eastern US), 5PM CET (Central Europe), 4PM 
GMT, 12AM (midnight) BST (Beijing)
* Zoom: 
* Google Calendar (click entry to add): 

https://openwhisk-team.slack.com/archives/C4J3R7JFL/p1550674823000100

2019-02-20 16:00:31 UTC - Matt Rutkowski: STARTING NOW! Apache OpenWhisk 
project Tech. Interchange meeting:

https://openwhisk-team.slack.com/archives/C4J3R7JFL/p1550678431000400

[slack-digest] [2019-02-20] #random

[OpenWhisk Team Slack]

2019-02-20 12:29:51 UTC - Carlos Santana: 

+1 : Dominic Kim
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1550665791005600

2019-02-20 13:07:48 UTC - James Thomas: trying to build a better lambda than 
aws on aws? that’s a bold strategy.
+1 : Dominic Kim
rolling_on_the_floor_laughing : Satwik Kolhe
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1550668068006300

2019-02-20 13:11:43 UTC - Rob Allen: _Courageous_, even
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1550668303006900

2019-02-20 13:17:59 UTC - Thomas Peikert: :laughing:
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1550668679007100

2019-02-20 20:36:41 UTC - Carlos Santana: 

https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1550695001000300

2019-02-20 20:37:22 UTC - Carlos Santana: 
 cc @Michele Sciabarra @Rodric 
Rabbah 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1550695042000700

[slack-digest] [2019-02-20] #general

[OpenWhisk Team Slack]

2019-02-20 06:50:59 UTC - Lars Andersson: @dubee All tests seem to have passed. 
This was not a modification to the API, just how the output was rendered by the 
client-go component.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550645459149600?thread_ts=1550569355.136300=C3TPCAQG1

2019-02-20 11:17:20 UTC - Satwik Kolhe: Need help with this : What is the 
concurrency min/max/std limit mentioned in values.yaml 
(whisk.limits.actions.concurrency) while deploying openwhisk using helm? How is 
this different from whisk.limits.actionsInvokesConcurrent?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550661440150900

2019-02-20 13:21:46 UTC - Dominic Kim: @Satwik Kolhe I think the first one is 
intra-container concurrency, while the second one is action concurrency.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550668906000700

2019-02-20 13:22:52 UTC - Dominic Kim: So you can invoke 3 invocations 
concurrently with 3 `actionsInvokesConcurrent` and can invoke 3 invocations 
using one container with 3 `whisk.limits.actions.concurrency`
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550668972001800

2019-02-20 13:23:41 UTC - Satwik Kolhe: Cool. Thanks.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550669021002100

2019-02-20 14:35:16 UTC - Satwik Kolhe: @Michele Sciabarra I found a way to 
deploy ow using persistent storage (following our last discussion of using rook 
to deploy ow) - by creating pv using "data" storageclass. This essentially 
works like volume-mount in docker. You need to define pv and pvc before 
deploying ow using helm (in the same namespace in which pvc's are created). And 
when redis, couchdb etc spin-up and use pvc, all the specified directories are 
created on appropriate k8s nodes, and your data is stored locally (which can be 
mounted on nfs as well). Its the simplest form of providing pv to pods in k8s.
Additionally I had to edit the helm/openwhisk/templates/*-pvc.yaml to use use 
existing (already created) pvc for the ow deployment.

Please check the yaml below for reference.

```kind: PersistentVolume
apiVersion: v1
metadata:
  name: couchdb-pv
spec:
  storageClassName: data
  capacity:
storage: 5Gi
  claimRef:
namespace: enfn-stage-1
name: couchdb-pvc
  accessModes:
- ReadWriteMany
  hostPath:
path: "/ow-data/couchdb/"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: couchdb-pvc
  namespace: enfn-stage-1
spec:
  storageClassName: data
  accessModes:
- ReadWriteMany
  resources:
requests:
  storage: 5Gi```

Please let me know if this is of any help for the community!
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550673316008800

2019-02-20 15:00:20 UTC - Slackbot: Reminder: Web Meeting: Tech Interchange 
(bi-weekly): 
* Day-Time: Wednesdays, 11AM EST (Eastern US), 5PM CET (Central Europe), 4PM 
GMT, 12AM (midnight) BST (Beijing)
* Zoom: 
* Google Calendar (click entry to add): 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p155067482100

2019-02-20 15:32:45 UTC - James Thomas: 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550676765000400

2019-02-20 16:00:27 UTC - Matt Rutkowski: STARTING NOW! Apache OpenWhisk 
project Tech. Interchange meeting:

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550678427000700

2019-02-20 16:01:04 UTC - Rodric Rabbah: hahah Whiskers Assemble
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550678464000900

2019-02-20 16:23:34 UTC - Rodric Rabbah: @Matt Rutkowski, question for post 
zoom: instead of modifying the runtime to bypass init, did you consider leaving 
the runtime alone and modifying the invoke protocol so that for some annotated 
actions it skips calling `/init`. I understood from the presentation that the 
code is bundled into the container already — like our blackbox/docker images 
where init is just a no-op. Does this reduce some of the complexity in 
“forking” the runtimes?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550679814002000

2019-02-20 16:24:38 UTC - Rodric Rabbah: ah… from the demo maybe i 
misunderstood… did the “run” receive the function code?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550679878002400

2019-02-20 16:37:12 UTC - Carlos Santana: Finally someone wrote the tool I 
always wanted :raised_hands:  :whisking:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550680632003200

2019-02-20 16:38:19 UTC - Rodric Rabbah: bad name :smile:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550680699003400

2019-02-20 16:38:31 UTC - Rodric Rabbah: ibm ovehead is _
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1550680711003900

2019-02-20 16:39:02 UTC - Rodric Rabbah: but def looking like a great tool for 
measuring openwhisk perf 

[slack-digest] [2019-02-20] #apigateway

[OpenWhisk Team Slack]

2019-02-20 16:00:25 UTC - Matt Rutkowski: STARTING NOW! Apache OpenWhisk 
project Tech. Interchange meeting:

https://openwhisk-team.slack.com/archives/C3TP33Y2U/p1550678425000200

Re: Feeds and fully resolving the trigger name

[Rodric Rabbah]

I neglected a "fix the docs" only approach: we can update the docs to say
the trigger name may use the implicit namespace, and that it's the provider
action's responsibility to resolve the namespace fully... which the current
openwhisk providers are doing anyway.

-r

On Wed, Feb 20, 2019 at 4:10 PM Rodric Rabbah  wrote:

> Hello,
>
> This email is related to event feeds - see [1] for a refresher.
>
> In looking through some code for the providers, I noticed that when a user
> creates an event feed, the request carries a trigger name that is not fully
> resolved.
>
> For example, when creating an alarm feed,
>wsk trigger create t --feed whisk.system/alarms/once ...
>
> The feed provider receives the following request:
> {
>   "authKey":"...",
>   "lifecycleEvent":"CREATE",
>"triggerName":"/_/t"
> }
>
> The trigger name isn't fully resolved as it uses the implicit/placeholder
> `_`. This means the feed handler has to resolve the namespace. It can do
> this by doing a lookup using the provided key against the openwhisk
> controller:
>
>GET https://apikey@apihostt/api/v1/namespaces
>
> In the providers I looked at, the namespace is being resolved another way:
> by using the __OW_NAMESPACE activation context value. This is OK as well
> but if we just treat the feed creation as an arbitrary API call, this won't
> work. So either the client has to resolve the trigger name fully, or the
> provider has to do it (or both?).
>
> I am contemplating a change to the feed specification to make the trigger
> name fully qualified (ie no underscore) and so clients must do this and
> providers can reject requests that don't conform.
>
> This is a solicitation for comments. I've created an issue as well
> https://github.com/apache/incubator-openwhisk/issues/4300
>
> [1]
> https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#implementing-feed-actions
>
> -r
>

Feeds and fully resolving the trigger name

[Rodric Rabbah]

Hello,

This email is related to event feeds - see [1] for a refresher.

In looking through some code for the providers, I noticed that when a user
creates an event feed, the request carries a trigger name that is not fully
resolved.

For example, when creating an alarm feed,
   wsk trigger create t --feed whisk.system/alarms/once ...

The feed provider receives the following request:
{
  "authKey":"...",
  "lifecycleEvent":"CREATE",
   "triggerName":"/_/t"
}

The trigger name isn't fully resolved as it uses the implicit/placeholder
`_`. This means the feed handler has to resolve the namespace. It can do
this by doing a lookup using the provided key against the openwhisk
controller:

   GET https://apikey@apihostt/api/v1/namespaces

In the providers I looked at, the namespace is being resolved another way:
by using the __OW_NAMESPACE activation context value. This is OK as well
but if we just treat the feed creation as an arbitrary API call, this won't
work. So either the client has to resolve the trigger name fully, or the
provider has to do it (or both?).

I am contemplating a change to the feed specification to make the trigger
name fully qualified (ie no underscore) and so clients must do this and
providers can reject requests that don't conform.

This is a solicitation for comments. I've created an issue as well
https://github.com/apache/incubator-openwhisk/issues/4300

[1]
https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#implementing-feed-actions

-r

Re: Notes + Video posted from today's OW Tech. Int. call

[Erez Hadad]

Hi Matt,

One small correction - My name is Erez, not Neeraj. I presented the 
overhead tool. 
I logged into cwiki to fix the notes but I don't seem to have any buttons 
to change anything in the page or even to post comments. 
Can you please [1] fix my name in the notes and [2] give me permissions 
for future occasions to edit the page or at least post comments?

Regards,
-- Erez

Erez Hadad, PhD
Cloud System Technologies
IBM Research - Haifa
email: er...@il.ibm.com
phone: +972-4-829-6509





From:   "Matt Rutkowski" 
To: dev@openwhisk.apache.org
Date:   20/02/2019 19:50
Subject:Notes + Video posted from today's OW Tech. Int. call



Thanks James for an excellent job as host.

Topic highlights:
- OpenWhisk runtimes in Knative (Matt/Priti)
- Benchmark Tool proposal (Nareej)

CWiki: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_OPENWHISK_2019-2D02-2D20-2BOW-2BTech-2BInterchange-2B-2D-2BMeeting-2BNotes=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=18puZfcSDwt_MbxySrCaW2xd_AoO8Fe1TE77vZD05ds=Fgy1AXa391U3trXQV_BS2IAOwG7uDcis8KNm8vEb24M=

YouTube: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__youtu.be_gJg8gOeYUX8=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=18puZfcSDwt_MbxySrCaW2xd_AoO8Fe1TE77vZD05ds=K3yQL2BizkvSZsMIXOgF3VDf89kt_GE7O7T2fNWgMjg=


Feel free to add comments/or changes to Cwiki as you see fit.

and another thanks to Rodric for volunteering to host the March 6th call 
in 2 weeks.

Kind regards,
Matt 

Re: Proposing a new performance benchmark tool for OpenWhisk - overhead

[Erez Hadad]

Hi Rodric,

Yes. I became aware of this issue when I read through OW code to map the 
activation timestamps to actual code stages. It's good to know that it's 
also documented.

Regards,
-- Erez

Erez Hadad, PhD
Cloud System Technologies
IBM Research - Haifa
email: er...@il.ibm.com
phone: +972-4-829-6509





From:   Rodric Rabbah 
To: dev@openwhisk.apache.org
Date:   20/02/2019 20:19
Subject:Re: Proposing a new performance benchmark tool for 
OpenWhisk - overhead



Erez, thanks for sharing the demo today. Really neat. You might know about 
this issue already which is relevant given the project you mentioned 
around rules and their performance. 

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_2614=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=8USWzgpVr-6bs5sUC_VBVzWdDeS8a1TXjCkwTAG0pu0=BPJm6LCDJctatfygqYGcQKOErdmJPLA9tOM8E_lOLuM=


-r

> On Feb 19, 2019, at 3:03 AM, Erez Hadad  wrote:
> 
> Hi folks,
> 
> I'm seeking feedback on a new performance benchmark tool called 
overhead, 
> that I'm proposing for OpenWhisk. This tool contains several new 
> capabilities beyond exiting tools (wrk/gatling), such as benchmarking 
> rules (trigger-to-action) in addition to action invocations (sync and 
> async), deeper profiling without special setup/instrumentation (Kamino), 

> based on timestamps from the activation records, and more. Please have a 

> look at the README.md for details.
> 
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IBM_overhead=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=8USWzgpVr-6bs5sUC_VBVzWdDeS8a1TXjCkwTAG0pu0=GlefpRYfckmFH6rDPuybLgk65iCQPKoJMmNJ_izYTeM=

> 
> Please review, use the tool, and comment - I'd like to contribute this 
> tool to the OW repo.
> 
> Regards,
> -- Erez
> 
> Erez Hadad, PhD
> Cloud System Technologies
> IBM Research - Haifa
> email: er...@il.ibm.com
> phone: +972-4-829-6509
> 
> 
> 

Re: Proposing a new performance benchmark tool for OpenWhisk - overhead

[Rodric Rabbah]

Erez, thanks for sharing the demo today. Really neat. You might know about this 
issue already which is relevant given the project you mentioned around rules 
and their performance. 

https://github.com/apache/incubator-openwhisk/issues/2614

-r

> On Feb 19, 2019, at 3:03 AM, Erez Hadad  wrote:
> 
> Hi folks,
> 
> I'm seeking feedback on a new performance benchmark tool called overhead, 
> that I'm proposing for OpenWhisk. This tool contains several new 
> capabilities beyond exiting tools (wrk/gatling), such as benchmarking 
> rules (trigger-to-action) in addition to action invocations (sync and 
> async), deeper profiling without special setup/instrumentation (Kamino), 
> based on timestamps from the activation records, and more. Please have a 
> look at the README.md for details.
> 
> https://github.com/IBM/overhead
> 
> Please review, use the tool, and comment - I'd like to contribute this 
> tool to the OW repo.
> 
> Regards,
> -- Erez
> 
> Erez Hadad, PhD
> Cloud System Technologies
> IBM Research - Haifa
> email: er...@il.ibm.com
> phone: +972-4-829-6509
> 
> 
> 

Notes + Video posted from today's OW Tech. Int. call

[Matt Rutkowski]

Thanks James for an excellent job as host.

Topic highlights:
- OpenWhisk runtimes in Knative (Matt/Priti)
- Benchmark Tool proposal (Nareej)

CWiki: 
https://cwiki.apache.org/confluence/display/OPENWHISK/2019-02-20+OW+Tech+Interchange+-+Meeting+Notes
YouTube: https://youtu.be/gJg8gOeYUX8

Feel free to add comments/or changes to Cwiki as you see fit.

and another thanks to Rodric for volunteering to host the March 6th call 
in 2 weeks.

Kind regards,
Matt 

Re: change the default action context to omit api key

[Rodric Rabbah]

> Existing demo apps which a new user might deploy and uses the SDK
> won't work.

Should we think about client side tooling to help? For js functions and zip 
files we can scan for occurrence of require(openwhisk) for example and generate 
a warning if the annotation is missing. 

This can lead to false positives when done with just a regex match but likely 
good enough. And of course it won’t capture all use cases where the api key is 
needed or work for all runtimes.

-r

Re: change the default action context to omit api key

[James Thomas]

This makes sense from a security POV. Given the potential for breaking user
applications[1] - we should try to document this as widely as possible. It
could probably do with a blog post.

I've opened an issue to add this to the JS SDK itself -
https://github.com/apache/incubator-openwhisk-client-js/issues/146

[1] - Existing demo apps which a new user might deploy and uses the SDK
won't work.

On Tue, 19 Feb 2019 at 15:24, Rodric Rabbah  wrote:

> Thanks to all the input here and on the PR - I think we ended up somewhere
> positive. Here's a summary:
>
> 1. for pre-existing actions that are already deployed, they're
> grandfathered in and will continue to behave in a way where they receive
> the api key on activation. This is done by detecting the absence of the new
> annotation.
> 2. the annotation is added on newly created actions only.
> 3. on update of pre-existing actions, the annotation is not added.
>
> The latest code which now passes all the previous and tests (for backward
> compatibility is here):
> https://github.com/apache/incubator-openwhisk/pull/4284
>
> -r
>
>
> On Thu, Feb 14, 2019 at 9:37 PM Rodric Rabbah  wrote:
>
> > I've implemented changes to the PR
> > https://github.com/apache/incubator-openwhisk/pull/4284 for backward
> > compatibility --- such that, actions which do not have the annotation
> will
> > still get the api key injected.
> >
> > The annotation is added by the controller when an action is created or
> > updated unless already present. The default value for the annotation is
> > "false", meaning no key is injected to the action context.
> >
> > Furthermore comments and feedback is appreciated.
> >
> > -r
> >
>


-- 
Regards,
James Thomas