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

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

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

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

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

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

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

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

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

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: change the default action context to omit api key

> 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

Re: change the default action context to omit api key

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 -

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://github.com/apache/incubator-openwhisk/issues/2614 -r > On Feb 19, 2019, at 3:03 AM, Erez Hadad wrote: >

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

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

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://cwiki.apache.org/confluence/display/OPENWHISK/2019-02-20+OW+Tech+Interchange+-+Meeting+Notes YouTube: https://youtu.be/gJg8gOeYUX8 Feel

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

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:

Feeds and fully resolving the trigger name

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

Re: Feeds and fully resolving the trigger name

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