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 gradu

Re: devtools and make-quickstart

For switching to standalone jar we would first need to publish it (#4525). Once we make it available for download somewhere we can then guide users to download it from there > I also like the standalone JAR. Should we consider adding to that the API Management features made available through OW GW

Re: Execute OpenWhisk action via Ignite and Firecracker VM (pr #4556)

> The quick impl. also shows our abstractions kinda work Indeed the ContainerFactory abstraction has so far worked well for many cases like Mesos, YARN, Ignite, AWS Lambda etc. Makes it easier to plugin any new execution approach easily. Chetan Mehrotra On Thu, Jul 18, 2019 at 6:07 PM Markus Thö

Re: A direction to take in a new component, "the scheduler"

Sven, all, That's a good call-out. In consequence to that: how about we discuss larger changes with a) a test script that simulates the types of load under discussion (and at the same time makes it clear which types of load are ignored for now) and b) a declaration of the KPIs one seeks to improv

Graduation Banner

I made a banner to celebrate graduation... maybe can be useful for Social Media posts? https://imgur.com/k47CKMx -- Michele Sciabarra mich...@sciabarra.com

Re: A direction to take in a new component, "the scheduler"

This is one of the situations where having some sort of proposal process can help align the various people and technical considerations a bit easier than mailing lists and PRs. There are numerous other communities with similar proposal processes (e.g., SIPs for Scala, KIPs for Kafka, JEPs and JSRs

Re: A direction to take in a new component, "the scheduler"

Hello Dominic and other discussion participants, we are in the great situation that Dominic (style95) volunteers to create and verify an alternative OpenWhisk architecture that may solve some of the problems that adopters of OpenWhisk may observe when running production systems with high utiliz

Re: Congratulations to Apache OpenWhisk, an Apache Top-level project ! (was: Progress towards graduation continues...)

Congratulations!!! On Thu, 2019-07-18 at 11:27 -0500, Matt Sicker wrote: > Hooray! > > On Thu, 18 Jul 2019 at 04:49, Erez Hadad wrote: > > Hear, hear! > > Cheers to all! > > > > Regards, > > -- Erez > > > > Erez Hadad, PhD > > Cloud System Technologies > > IBM Research - Haifa > > email: er...

Re: Congratulations to Apache OpenWhisk, an Apache Top-level project ! (was: Progress towards graduation continues...)

Hooray! On Thu, 18 Jul 2019 at 04:49, Erez Hadad wrote: > > Hear, hear! > Cheers to all! > > Regards, > -- Erez > > Erez Hadad, PhD > Cloud System Technologies > IBM Research - Haifa > email: er...@il.ibm.com > phone: +972-4-829-6509 > > > > > > From: Bertrand Delacretaz > To: OpenWhisk De

Re: Using Rust for the KnativeWhisk controller

Now in general, I'd suggest that we use the appropriate language for each concern. This should probably be balanced by the number of languages in use as well as how feasible it would be for a community to grow around it. Rust might be appropriate for certain components, though I don't know enough a

Re: Using Rust for the KnativeWhisk controller

I’ve barely used Go, and I agree with your rant. I usually just summarize by “no parametric polymorphism” and the language geeks can fill in the blanks of what type of language that results in. In that regard, I’d support using Go only in the areas where it makes sense. I’ve found it to be useful

Re: A direction to take in a new component, "the scheduler"

Ooh, I love feature flags. I don’t know enough details to say whether an incremental refactoring like that would work here, but it’s usually a better idea than a full rewrite. On Thu, Jul 18, 2019 at 08:07, Rodric Rabbah wrote: > We should put together a roadmap that shows the evolution and all

Re: A direction to take in a new component, "the scheduler"

We should put together a roadmap that shows the evolution and all presents a coherent view of all the moving parts. -r > On Jul 18, 2019, at 8:52 AM, Markus Thömmes wrote: > > Hi, > > this sounds a lot like the "OpenWhisk 2.0" discussion we had in an older > thread where I proposed an archit

Re: A direction to take in a new component, "the scheduler"

> It must not break any existing downstream system as well as the upstream > pipelines. So all implementations should be disabled by default along with > proper > switches. Agreed. There is a feature flag class that Chetan introduced when I introduced a breaking change (sorry) a few months ag

Re: A direction to take in a new component, "the scheduler"

Hi, this sounds a lot like the "OpenWhisk 2.0" discussion we had in an older thread where I proposed an architectural overhaul. See this thread for context: https://lists.apache.org/thread.html/d19306dd976138a153f48d32c5a55f2853e4b8ff405fc46f7260e905@%3Cdev.openwhisk.apache.org%3E There have been

Re: Using Rust for the KnativeWhisk controller

Ok, sorry for the rant. I hope I did not violate any code of conduct with this. I hope it is acceptable to say I feel coding in Go is painful for me, you have to care of a lot of small details, and I prefer to stick maintaining the Go runtime but I do not feel also coding a controller with it.

Re: Execute OpenWhisk action via Ignite and Firecracker VM (pr #4556)

Great stuff Chetan! The quick impl. also shows our abstractions kinda work. That makes me happy too :). Am Di., 16. Juli 2019 um 00:56 Uhr schrieb Carlos Santana < csantan...@gmail.com>: > Great work Chetan > > This must be a new record how fast to get a POC integrated in a few days > after ignit

Re: Using Rust for the KnativeWhisk controller

I share none of these sentiments. Neither on Golang being barebones nor on a few of the examples you mentioned making me "want to die" nor on "absurdities", "silliness" in the languages design or on an "absolute mess" others built with it. I have used the "lower barrier to entry means also a proli

A direction to take in a new component, "the scheduler"

Recently I discussed the direction and a safe way to add a new component with Sven Lange-Last. Let me share the discussion results. More feedbacks and critique are welcomed. Since the implementation includes a breaking architectural change, it comes with a risk. It must not break any existing down

Re: Using Rust for the KnativeWhisk controller

Sigh! Having used Go for over one year and half, and being the one who built the Go runtime and applied to another 5 languages, I know what is wrong with Go. Go is terribly bare-bone and expressing everything that is a bit complex is an excercise in patience. And a REST server is already too com

Re: Using Rust for the KnativeWhisk controller

Am Do., 18. Juli 2019 um 10:04 Uhr schrieb Michele Sciabarra < mich...@sciabarra.com>: > Actually, I am not going to rewrite the controller in Go. > There is already one here: https://github.com/projectodd/kwsk > > I proposed to use Rust instead since looks like it is growing fast, so I > could "p

Re: Congratulations to Apache OpenWhisk, an Apache Top-level project ! (was: Progress towards graduation continues...)

Hear, hear! Cheers to all! Regards, -- Erez Erez Hadad, PhD Cloud System Technologies IBM Research - Haifa email: er...@il.ibm.com phone: +972-4-829-6509 From: Bertrand Delacretaz To: OpenWhisk Dev Date: 18/07/2019 11:31 Subject:[EXTERNAL] Congratulations to Apache OpenWhi

Congratulations to Apache OpenWhisk, an Apache Top-level project ! (was: Progress towards graduation continues...)

Hi, On Thu, Jul 18, 2019 at 9:53 AM Rob Allen wrote: > I see that the July board meeting of the ASF that took place yesterday > contained this: > > The following resolutions were passed unanimously: ... > > Establish the Apache OpenWhisk Project (Dave Grove, VP) ... Yes indeed and this means g

Re: Progress towards graduation continues

This is great news. On Thu, 18 Jul 2019 at 08:53, Rob Allen wrote: > > I see that the July board meeting of the ASF that took place yesterday > contained this: > > > The following resolutions were passed unanimously: > > > > Update Apache Security Team Membership > > Change the Apache HBase Pr

[slack-digest] [2019-07-17] #general

2019-07-17 07:08:21 UTC - Adam Varsano: Hi, sorry for the delay, but when I try the docker container factory, the invoker pod didn't duplicate the containers but there was only 1 pod with 1 container https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1563347301013900?thread_ts=1562835976.333800

[slack-digest] [2019-07-17] #random

2019-07-17 16:27:43 UTC - Rodric Rabbah: congrats to the adobe team whisking : mmarth, Robert Felker, Shazron Abdullah https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1563380863037400

Re: Using Rust for the KnativeWhisk controller

Actually, I am not going to rewrite the controller in Go. There is already one here: https://github.com/projectodd/kwsk I proposed to use Rust instead since looks like it is growing fast, so I could "prototype" in Rust to see where we get. But since the community does not like it, I give up. My

Progress towards graduation continues

I see that the July board meeting of the ASF that took place yesterday contained this: > The following resolutions were passed unanimously: > > Update Apache Security Team Membership > Change the Apache HBase Project Chair (Duo Zhang, VP) > Establish the Apache OpenWhisk Project (Dave Grove,