Re: New OpenWhisk PMC Members: Brendan Doyle and Cosmin Stanciu

Huge congrats Cosmin, and Brendan On Wed, Feb 23, 2022 at 3:00 PM Dominic Kim wrote: > Nice! > Congratulations Brendan and Cosmin! > > Best regards > Dominic > > 2022년 2월 24일 (목) 오전 2:39, Tyson Norris 님이 작성: > > > Congratulations Cosmin and Brendan!!! > > > > Best, > > Tyson > > > > On

Re: [VOTE] Release Apache OpenWhisk Client Js (v3.21.5, rc1)

+1 to release it ! I also verified it successfully with rcverify ! Thanks Cosmin ! On Wed, Nov 3, 2021 at 12:12 PM Dave Grove wrote: > +1 to release openwhisk-client-js 3.21.5 from rc1. > > --dave > > Daves-MacBook-Pro:tools dgrove$ ./rcverify.sh openwhisk-client-js 3.21.5 > rc1 > rcverify.sh

Re: [DISCUSS] Upgrade Akka to 2.6.12

Just letting you know that this PR is now merged. Special thanks to Eugene Tulika for working on this PR, and also for fixing the Travis build which had issues due to a dependent lib [1] [1] - https://github.com/apache/openwhisk/pull/5121 On Mon, Mar 29, 2021 at 12:59 PM Dascalita Dragos wrote

Re: [VOTE] Release Apache OpenWhisk Command-line Interface (CLI) (v1.2.0, rc1)

+1 to release ! I tested with rcverify and all tests passed as expected. My highlight: .rs files are automatically recognized as Rust kind ! On Mon, Mar 29, 2021 at 1:57 PM Dave Grove wrote: > +1 to release openwhisk-cli v1.2.0 from rc1. > > reverify log appended. > > --Dave > >

[DISCUSS] Upgrade Akka to 2.6.12

Hi, We have this nice contribution by Eugene Tulika [1] which has recently taken the endeavor of upgrading our project to Akka 2.6.12. Thanks Eugene ! Eugene and I work together; we wanna share some improvements for sync web actions on a separate PR, but before that, there are two PRs to be

Re: [Review]Change return status code for ApplicationError and DeveloperError

While we're on the status code topic I'd like to share some feedback we got from developers using OpenWhisk. They have complained that for blocking activations, when the system can't execute the action, they get a 202 instead. The feedback was that it's not correct for a system to override the

Re: Proposal: Adding Support for Juypter Notebooks

Michele, this is awesome. I'm so appreciative for building on the existing "pythonaiaction". Thanks for updating it to the latest Tensorflow. I think there's a lot of value in running AI Actions in a serverless fashion to quickly build AI APIs (inference mainly; training is a separate topic

Re: [VOTE] Release Apache OpenWhisk Client Js (v3.21.2, rc1)

+1 Release verification checklist (tested with rcverify.sh): [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are correct for each OpenWhisk repository. [x]

Re: [VOTE] Accept wskdebug contribution from Adobe

Big +1 too ! On Fri, Feb 21, 2020 at 8:28 AM Rob Allen wrote: > +1 > > Thanks Adobe team. > > Regards, > > Rob > > > On 20 Feb 2020, at 17:35, David P Grove wrote: > > > >  > > > > This is a call to vote to accept the donation of the wskdebug code base > > from Adobe as discussed in [1]. This

Re: recent openwhisk-runtime-* releases

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

Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.15.0, rc1)

+1 Verified with rcverify tool, log appended. Thanks, dragos rcverify.sh (script SHA1: 8DD4 A0E6 7974 CB8F E859 B403 9463 852F 2749 E23D) working in the following directory: /var/folders/zy/xhbjcqg12w1182qx447mdz10gn/T/tmp.ywS1on4g fetching tarball and signatures from

Re: Requesting feedback about the new typescript runtime

for node. There was also no support for intra container > concurrency. > > -r > > > On Jan 9, 2020, at 8:04 PM, Dascalita Dragos wrote: > > > > The argument that the way this new runtime is constructed is very > different > > from the existing nodejs one

Re: Requesting feedback about the new typescript runtime

The argument that the way this new runtime is constructed is very different from the existing nodejs one, seems a strong one in my opinion to consider a dedicated repo. The unclear part to me is whether it would make sense to consider applying the “action loop” pattern to the existing NodeJs

Re: Welcome new Committer Shawn Black

Warm welcome Shawn ! On Sun, Dec 15, 2019 at 7:46 AM Chetan Mehrotra wrote: > Welcome Shawn!! > > On Tue, Dec 3, 2019, 4:49 AM Rodric Rabbah wrote: > > > It is my pleasure to share that the OpenWhisk PPMC has elected Shawn > Black > > as a Committer, based on his ongoing and valuable

Re: API Gateway routing on Mac

I didn’t check the recording but How is the URL for the action retrieved ? On Mon, Nov 18, 2019 at 10:05 AM Tom Barber wrote: > Hmm, good catch I didn't spot that. Its all created dynamically by the > serverless deploy routine the entirety of which looks like: >

Re: Composer requires Redis but NodeJS Runtime doesn't include it

e it > > > > +1 for including redis in runtimes. > > > > -r > > > > On Tue, Oct 1, 2019 at 10:06 AM Dascalita Dragos > wrote: > > > > > Currently there's an issue with Composer which requires Redis [1]. > Redis > > > module is not

Composer requires Redis but NodeJS Runtime doesn't include it

Currently there's an issue with Composer which requires Redis [1]. Redis module is not installed by default in the NodeJS images. I see 2 options to unblock this: 1 - include Redis in the default nodeJS runtime [2] 2 - make Redis optional for Composer; parallel combinator in Composer won't work

Re: Can we adjust the time for the community call

I'm PST but I'm ok with 7AM PST. I've been fighting to reschedule early meetings in order to join OW community calls many times; moving it 1 hr early would allow me to participate too. On Thu, Sep 5, 2019 at 6:51 PM Dominic Kim wrote: > Thank you all for the warm words. > > Actually, 1 hour

Re: Re: Changing JavaScript SDK NPM Module Name: openwhisk => apache-openwhisk?

James, the way I'm imagining what could be done to update the name: (1) deprecate "openwhisk" module with "npm deprecate" [1] so that everyone gets the warning and (2) publish "apache-openwhisk" with the same version as "openwhisk", and update this one going forward. For (1) we could plug OW

Re: Using Rust for the KnativeWhisk controller

I’m inserting my +1 for Go, based on the community adoption of Go; my perception is that it found its place as the de-facto language for managing infrastructure. Akka is amazing for distributed programming model ... that’s my only argument for Scala, but this argument alone is not strong enough to

Re: devtools and make-quickstart

"...we should pin all the dependent images etc and make a release available" +1 I also like the standalone JAR. Should we consider adding to that the API Management features made available through OW GW, or for that we should keep the docker-compose route ? On Fri, Jul 12, 2019 at 8:53 AM

Re: api gateway with standalone controller

Rodric, are you running a custom api gateway container ? The lines at [1] should fix the issue for you. NGINX has its own internal DNS resolution for performance considerations. I'm curios what the content of "/etc/api-gateway/conf.d/includes/resolvers.conf" is inside the apigateway container.

Re: [VOTE] Apache OpenWhisk graduation to Top Level Project

Big +1 Amazing milestone. Many thanks for the the people involved in moving the project to this state. On Wed, Jun 5, 2019 at 2:06 PM Priti Desai wrote: > +1 yup, definitely, its been a great pleasure working with the community! > > Cheers > Priti > > On 2019/06/04 21:25:28, Rodric Rabbah

Re: A plan to (re) implement OpenWhisk on top of Knative

Thanks for taking the time to do this POC Michele. I'm looking forward for learn about the cold-start times with KNative. On Fri, May 24, 2019 at 8:48 AM Michele Sciabarra wrote: > I am taking all the suggestions and trying to setup a first implementation. > > > -- > Michele Sciabarra >

Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc2)

[x] +1 Approve the release Release verification checklist for reference: [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] DISCLAIMER is included. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are

Re: New architecture proposal

be made) by the others at the same time. > So we need to track down all container status, consider all decision made > by multiple components and finally make the optimal decision to delete > containers within 2 ms. > I think this is not viable. > > Your idea sounds great, it

Re: New architecture proposal

urrent behavior you can still have a similar > effect by configuring the timeout as 50ms. > (So containers will only wait for 50ms, though it may induce some > performance degradation in other cases.) > > Best regards > Dominic > > > 2019년 4월 10일 (수) 오전 1:36, Dascalita Dra

Re: New architecture proposal

> > > request and invoke it. > > > In this sense, we can maximize the container reuse. > > > > > > When there is no more activation message, ContainerProxy will be wait > for > > > the given time(configurable) and just stop. > > > One difference i

Re: New architecture proposal

Hi Dominic, Thanks for sharing your ideas. IIUC (and pls keep me honest), the goal of the new design is to improve activation performance. I personally love this; performance is a critical non-functional feature of any FaaS system. There’s something I’d like to call out: the management of

Re: [Bi-Weekly Tech Interchange] Call for agenda topics

oxy - it'll only take 5 - 10 > mins. > > On Tue, 19 Mar 2019 at 17:26, Priti Desai wrote: > > > Hi Dragos, > > > > Please reserve 10 to 15 minutes for Knative buiid. > > > > Cheers > > Priti > > > > > > > > From: Dascalita D

[Bi-Weekly Tech Interchange] Call for agenda topics

Hi, I'm starting this thread to start capturing topics to discuss for our call tomorrow. Please reply to this email to reserve your spot ! Bi-weekly Tech Interchange call details: - Zoom: https://zoom.us/my/asfopenwhisk - Wednesday March 20th 11AM EST(Eastern US) 5PM CET (Central Europe), 4PM

Re: [DISCUSS] Release event providers

+1 as well for 2.0.0 On Mon, Mar 18, 2019 at 10:58 AM James Thomas wrote: > +1 on going with 2.0.0 and moving forward with the release. > > On Sun, 17 Mar 2019 at 12:57, Carlos Santana wrote: > > > +1 > > > > - Carlos Santana > > @csantanapr > > > > > On Mar 16, 2019, at 3:54 PM, David P Grove

Re: [DISCUSS] graduation from the incubator

Huge +1 from my side as well. I couldn't agree more. I think the project not only has momentum, but it's also used in production environments and it's well tested and stable. In addition, I believe multiple parties have long term visions with enhancements, which IMO I see it as a positive

Re: PR to enable actions on YARN

Hi Samuel, This is an interesting contribution. Do you happen to have any performance numbers with YARN ? I'd be particularly interested in the cold start latencies. Thanks, dragos On Fri, Feb 22, 2019 at 5:21 PM Samuel Hjelmfelt wrote: > > Hi Rodric and Carlos, > > > ApacheHadoop has three

Re: Agenda Items for Tech Interchange this Wed (December 5th)

If time allows I can show PR https://github.com/apache/incubator-openwhisk/pull/4142 , enabling developers to run both controller and invoker from IntelliJ locally, for both docker-compose and ansible deployments (5 mins) On Tue, Dec 4, 2018 at 2:59 PM Priti Desai wrote: > Thanks Moritz, Erez,

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating-rc1: OpenWhisk Composer

+1 on the release. Just verified the checklist as well. On Mon, Nov 26, 2018 at 9:01 AM Tyson Norris wrote: > +1 to release Apache OpenWhisk 0.9.0-incubating: OpenWhisk composer > > Verified checklist > > Thanks > Tyson > > On 11/20/18, 11:30 AM, "David P Grove" wrote: > > > > This is

Re: Where and how do you deploy Apache OpenWhisk?

Hi Ben, Thanks for starting this thread. I'll chime in with my POV. I see the deployment largely structured around 3 layers: 1. Container Management. This layer contains logic to spin up a Kubernetes or Mesos cluster. It could be a managed cluster ( Azure Container Service, Amazon ECS for

Bi-weekly Tech Interchange call tomorrow - add agenda topics here

Hi, Please add to this thread any agenda items you'd like to discuss at the Tech Interchange call tomorrow. Call details: Web Meeting: Tech Interchange (bi-weekly): - Day-Time: Wednesdays, 11AM EDT (Eastern US), 5PM CEST (Central Europe), 3PM UTC, 11PM CST (Beijing) - Zoom:

Re: Bi-weekly Tech Interchange call tomorrow

Hi Tyson, I also had the AI Action proposal from the last meeting. On Tue, Aug 28, 2018 at 2:58 PM Vincent S Hou wrote: > Hi Tyson, > > I want to introduce the status of release, the plan to release runtimes, > and the future version management. > Thank you. > > Best wishes. > Vincent Hou (侯胜博)

Re: Prototyping for a future architecture

I also click on the clean and lean upgrade path, with gradual improvements to the existing system (which is production-proof), as Michael and Rodric are suggesting. At the same time I see how Go would make sense from the Kubernetes and Knative impl POV, how the trends favor Go over Scala [1],

Re: Prototyping for a future architecture

I highly support the idea to start experimenting to help us make more informed decisions vs basing decisions on assumptions. Should we also agree on a performance goal (aside from the other goals you called out ) ? I'm thinking at setting a performance goal i.e. run X/requests per second on a

Re: Kafka and Proposal on a future architecture of OpenWhisk

“... FWIW I should change that to no longer say "Kafka" but "buffer" or "message queue"...” +1. One idea could be to use Akka Streams and let the OW operator make a decision on using Kafka with Akka Streams, or not [1]. This would make OW deployment easier, Kafka becoming optional, while opening

Re: Notes & Video posted from today's Tech. Interchange meeting

Matt, echoing again my thanks for such great notes. Not being able to attend today, it was valuable to get the summary in between my flight connections. Kudos ! On Wed, Aug 15, 2018 at 12:23 PM Matt Rutkowski wrote: > Thanks Ben for moderating a very full agenda with lots of good > discussions.

Re: Pluggable API Gateways

I’d +1 Rodric’s suggestion with subdirs until we group a few implementation together in the repo, and decide at that point on splitting into separate repos or not. On Fri, Aug 10, 2018 at 10:48 PM Rodric Rabbah wrote: > > One possibility would be to create a layer that sits in between Whisk > >

Re: Pluggable API Gateways

I assume Henry's suggestion is to colocate (as a start) APIGW + apimgmt actions in a folder, probably in "incubator-openwhisk-apigateway". In that repo there would be a folder for each impl: GW + apimgmt together. Henry please keep me honest here. I assume that apimgmt tests would also move along.

Re: System env vars in user containers

RE “context” object it’s interesting to observe what other FaaS providers do in that regard. See, AWS [1], Azure [2], and Google [3]. If we want to later support (a) concurrency AND (b) “raw” requests ( as in No Objects, imagine the “raw” param being a JPEG image ) then the added “context” param

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating

A big +1 On Wed, Jun 20, 2018 at 2:16 PM Vincent S Hou wrote: > Hi everyone, > > This is to call for a vote for the release of Apache OpenWhisk > 0.9.0-incubating. > > List of JIRA ticket(s) resolved for this release can be found at > https://issues.apache.org/jira/browse/INCUBATOR-213. > > To

Re: Supporting user-configurable warm action containers?

Acknowledging that dev cycles, performance tests, or other spiky traffic may not be initially captured, I would put my $$$ on teaching OW how to learn the traffic pattern and let it pre-warm based on that. There are existing algorithms that could be used for prediction, if we just have the

Re: Sending activation metadata to Kafka

Continuing what Rodric was saying I'd also like to bring into this picture Distributed Tracing from this older PR [1]. A holistic approach of "what to use, when, and for what purpose" would be useful. [1] - https://github.com/apache/incubator-openwhisk/pull/2282 On Tue, Apr 17, 2018 at 2:59 PM

Any topics for tomorrow's Tech Interchange meeting? @4pm GMT / 11am EST / 8am PST

Does anyone have any agenda items to discuss? This can include discussion of Issues, PRs, Feature ideas, How-To's, Docs, Demos, just about anything OW related... Current (typical) agenda: 1. Introduction/New faces on the call? (5 mins) 2. Asking around for notable changes/updates? (5 min)

Reminder: OW Tech Interchange call tomorrow, Jan 17rd, 4pm GMT, 10am US EST, 8am US PST

Just a reminder for our "Tech Interchange" (bi-weekly) tomorrow. --- Topic: Apache OpenWhisk "Tech. Interchange" (bi-weekly) Zoom Meeting Time: this is a recurring meeting Meet anytime Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/asfopenwhisk Or iPhone one-tap (US Toll):

Re: Performance tests for OpenWhisk

+1 to the idea of having 1 machine dedicated to running action containers only. We've also taken Markus' repo a step further with a distributed testing tool named Locust.io [1] . The tests are at [2]. I've also used Tsung [3] on other projects (it's based on Erlang). Tsung provides the best

Re: terraform wskdeploy plugin demo

Nice work David ! Would you be able to highlight the advantages you observed from using terraform with wskdeploy ? Were you able to also factor in terraform's state ? Thanks, Dragos On Thu, Jul 6, 2017 at 10:34 PM David ZL Liu wrote: > Greetings, > > I made a simple demo

Re: Improving support for UI driven use cases

> The prototype PR from Tyson was based on a fixed capacity of concurrent activations per container. From that, I presume once the limit is reached, the load balancer would roll over to allocate a new container. +1. This is indeed the intent in this proposal. > a much higher level of complexity

Re: Improving support for UI driven use cases

lex policies (eg scale > based on cpu or mem utilization, end-user response time, etc.? What are the > thresholds for when to add/remove capacity?), and a value prop of > serverless is that folks don't have to care about that. > > we should discuss more during the call, but wanted to get th

Re: Improving support for UI driven use cases

Michael , +1 to how you summarized the problem. > I’d suggest that the first step is to support “multiple heterogeneous resource pools” I'd like to reinforce Stephen's idea on "multiple resource pools". We've been already using this idea in production systems successfully in other setups, with

Re: Improving support for UI driven use cases

> How could a developer understand how many requests per container to set James, this is a good point, along with the other points in your email. I think the developer doesn't need to know this info actually. What stops Openwhisk to be smart in observing the response times, CPU consumption,

Re: Improving support for UI driven use cases

> I think the opportunities for packing computation at finer granularity will be there. In your approach you're tending, it seems, toward taking monolithic codes and overlapping their computation. I tend to think this will work better with another approach. +1 to making the serverless system

Re: PassportJS with OpenWhisk

t; > [1] > > https://medium.com/openwhisk/deploying-express-js-apps-to-openwhisk-part-1-9133ba5f262c > [2] https://www.npmjs.com/package/openwhisk-expressjs > [3] https://github.com/lionelvillard/openwhisk-expressjs > > > --Carlos > > > On Mon, May 8, 2017 at 11:

PassportJS with OpenWhisk

Recently I’ve been trying to see if we can reuse PassportJS with OpenWhisk in order to create a User Authentication experience in a Serverless fashion. PassportJS is a Node library that supports 300+ authentication providers and this is what made it appealing. The use-case I was after was to

Re: concurrent requests on actions

Why not considering giving developers options to control the level of concurrency, instead of deciding on their behalf ? I think that cases such as the ones Tyson is mentioning make sense; unless we build something that will estimate the resources needed by an action automatically, letting the

Re: API Gateway

Hi Jugaadi, This is a good idea. There is already a Kong Plugin for OpenWhisk - [1]; it's limited in functionality when compared with the current Openwhisk Gateway - [2] . But the community could enhance the Kong plugin and it can be used by people who are already familiar with Kong. The current

Re: New ContainerPool

; > James Thomas has done some work around zipkin & openwhisk. Is that what > > you're looking for? > > > > https://www.npmjs.com/package/zipkin-instrumentation-openwhisk > > > > Sent from my iPhone > > > > > On 4 Apr 2017, at 23:50, Dascalit

Re: New ContainerPool

This looks very promising Markus ! Great work ! I'm wondering if anyone is currently looking into integrating HTrace and Zipkin; if there's no on-going effort I'm interested to do this. At least my team and I are interested in getting a distributed tracing solution in place, helpful in

Re: factoring out "runtimes" into deployment configuration

no docker pull. And this is doable today > already. What am I missing from your explanation? > > -r > > On Mar 9, 2017, at 6:44 PM, Dascalita Dragos <ddrag...@gmail.com> wrote: > > >> Isn't that what we call "blackbox" (docker) actions now? > > >

Re: Configuration through environment vs. Consul KV

*"...**pushing the images we build to **DockerHub** (a couchdb image included)"* I'm working with my team these days at the CouchDB image. Should we include it now in the repo or push it when we're ready to push the other images too ? Thanks, Dragos