Long running invocations and status code (was : [Review]Change return status code for ApplicationError and DeveloperError)

[Felix Meschberger]

Hi all

I am a bit on the edge here: I really like the server (OpenWhisk controller ?) 
to terminate the request with a 202 indicating that the processing continues. 
On the other hand, this really might be coming unexpectedly as it is not very 
mainstream.

How about a compromise ?

RFC 7240 (https://tools.ietf.org/html/rfc7240) defines the Prefer request 
header whether the client can provide a preference for request processing. One 
use case would be to state "please synchronous, but if it takes longer than 
30s, continue asynchronously".

Granted, this allows clients to indicate their preference, but it does not 
solve the hard problem of "aborting" the invocation: In fact if the invocation 
being executed, then what would "abort" mean anyways ?

Just my 2 cents from the peanut gallery

Regards
Felix


Von: Rodric Rabbah 
Gesendet: Dienstag, 26. Januar 2021 06:31
An: dev@openwhisk.apache.org
Betreff: Re: [Review]Change return status code for ApplicationError and 
DeveloperError

Thanks for sharing this feedback from developers, Dragos.

Like the PR from Jiang, this is a one line change in terms of the status
code. Cancelling the request is harder but could be accomplished by
attaching a deadline on an activation request and allowing the invokers to
discard them on receipt if they're past their deadline.

I agree for a request/response model, downgrading a synchronous request to
an asynchronous one isn't ideal.

-r


On Mon, Jan 25, 2021 at 9:41 PM Dascalita Dragos  wrote:

> 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 intention of the developer, and that
> the correct response should be an error status code. The system should also
> stop the execution to avoid wasting resources. Since OpenWhisk actions can
> be invoked from a browser too (HTML content, or other content type that can
> be displayed by the browser), dealing with a 202 becomes complicated, and
> it's not in line with its purpose either [1] "cases where another process
> or server handles the request, or for batch processing".
>
> [1] - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202
>
> On Mon, Jan 25, 2021 at 7:00 AM Rodric Rabbah  wrote:
>
> > Thanks Jiang for addressing this long standing bug.
> >
> > I reviewed the PR. The 400 status code for developer errors also matches
> > the web action response. I think the only real debate is whether
> > application error should be 207 or 400. If a web action responds with an
> > error and no explicit status code, is it treated as a 20x response. So I
> > find the change in your PR consistent.
> >
> > There may be some effects to check in the npm client and the wsk (or
> other
> > clis).
> >
> > -r
> >
> > On Mon, Jan 25, 2021 at 1:19 AM 蒋鹏程 
> wrote:
> >
> > > Dear whiskers:
> > > ​
> > >   Currently we are using 502 BadGateway for ApplicationError and
> > > DeveloperError, which is not very appropriate I think, so I submit a PR
> > to
> > > change this:
> > > ​
> > > 1. Use MultiStatus for ApplicationError
> > > 2. Use BadRequest for DeveloperError
> > > ​
> > > Any comments and suggestions are welcomed
> > > ​
> > > refs:
> > > 1.
> https://github.com/apache/openwhisk/issues/645#issuecomment-232534948
> > > 2. https://github.com/apache/openwhisk/pull/5047
> > > ​
> > > Best Regards
> > > Jiang Pengcheng
> > >
> > > ​
> > >
> >
>

Re: Openwhisk in a standalone runnable jar (#4516)

[Felix Meschberger]

Wow ! This goes a long way to developer ease of getting to know.

Kudos !

Regards
Felix

> Am 18.06.2019 um 15:22 schrieb Chetan Mehrotra :
> 
> Hi Team,
> 
> Recently based on some feedback by end users I felt a need for a
> simpler way to test out OpenWhisk for end users. Towards that end
> there is a new PR #4516 which enables launching OpenWhisk as a simple
> runnable jar.
> 
> java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar
> 
> Post this OpenWhisk server would be accessible over 8080 port and wsk
> can be configured to us that
> 
> More details are provided at #4516 [1].
> 
> Thoughts?
> 
> Chetan Mehrotra
> [1] https://github.com/apache/incubator-openwhisk/pull/4516

Re: I created a variant of the go runtime that is faster at init time

[Felix Meschberger]

Hi Michele

This is shaky ground and we don’t want to be the next npm horror story.

Technically speaking, at Apache we primarily release source packages, all 
binary is pure convenience. Granted the convience today is what most people use.

So what we should primarily do, as Bertrand hinted, is have a contrib 
repository. We can still have a contrib docker account into which the OpenWhisk 
PMC can regularly „dump“ binary builds for convience. But it must be clearly 
stated that those are not releases, have no release quality and all the usual 
disclaimers.

Regards
Felix

> Am 12.12.2018 um 10:55 schrieb Michele Sciabarra :
> 
> Actually more than an account on GitHub it is important to have a docker hub 
> account named "openwhisk-contrib" so you can deploy an action with something 
> like:
> 
> wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
> 
> To publish images, you can do sothing as simple as ask, maybe opening a 
> ticket, to push an image msciab/actionloop-gccgo-v1.10
> to  openwhisk-contrib/actionloop-gccgo-v1.10.  
> 
> 
> 
> -- 
>  Michele Sciabarra
>  mich...@sciabarra.com
> 
> - Original message -
> From: Bertrand Delacretaz 
> To: dev@openwhisk.apache.org
> Subject: Re: I created a variant of the go runtime that is faster at init time
> Date: Wed, 12 Dec 2018 10:45:43 +0100
> 
> Hi,
> 
> On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
>  wrote:
>> 
>> Indeed I was thinking to create a docker account  "openwhisk-contrib" to 
>> place those, let's say, unofficial images.
>> I am not sure who should own this account...
> 
> Accounts with "openwhisk" in their name should be owned by the
> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> Foundation - technically being donated as we speak IIUC but that
> doesn't make a real difference.
> 
> However what we are discussing here IMO is code repositories as code
> is what the ASF produces. I guess Felix's suggestion is to create one
> or a few openwhisk-contrib-* Git repositories under
> https://github.com/apache/ for such "contrib" modules.
> 
> -Bertrand

Re: I created a variant of the go runtime that is faster at init time

[Felix Meschberger]

Hi Michele

„Dynamic libraries included in the container" was the answer I was looking for. 
Thanks

Regards
Felix

> Am 12.12.2018 um 10:49 schrieb Michele Sciabarra :
> 
> To answer to the second part of your question:
> 
> if you compile a Go program with the native go compiler, the final executable 
> links statically everything including the garbage collector and other stuff. 
> If you use gccgo, those things are dynamic libraries and are not included in 
> the executable.
> 
> I created the gccgo image using ubuntu (bionic) and installing the gccgo 
> package, hence all the required dynamic libraries are included in the docker 
> image. 
> 
> Furthermore, the executable is created by the image itself (using the 
> precompilation feature of the "actionloop" image) so the executable is 
> created BY the image FOR the image and the dynamic libraries match.
> 
> The same happens for the switf image, to create say an executable for swift 
> 4.2.1 you have to use the image for swift 4.2.1 with the -compile flag, and 
> it will produce an action that can be run in the same image.
> 
> -- 
>  Michele Sciabarra
>  mich...@sciabarra.com
> 
> - Original message -
> From: Felix Meschberger 
> To: "dev@openwhisk.apache.org" 
> Subject: Re: I created a variant of the go runtime that is faster at init time
> Date: Wed, 12 Dec 2018 09:09:58 +
> 
> Hi
> 
> From the sidelines…
> 
> I understand that there is limited bandwidth to support all sorts of runtimes 
> .. But I wonder, whether such a thing would not have a space in some sort of 
> an „unsupported“ contrib area ?
> 
> I myself like the idea of smaller binaries but wonder how you solve the 
> dynmic linking issue of provisioning the dependency dynamic libraries in the 
> container ?
> 
> Regards
> Felix
> 
>> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra :
>> 
>> I am perfectly fine if we do not provide a gccgo runtime, it was not a big 
>> work, and I did it to see if it is possible to generate small executables 
>> also for go, since the swift one is very small. 
>> 
>> Aside from the fact that actionloop-gccgo-v1.10  is the faster runtime both 
>> in run and init time (a personal satisfaction) if the init time is NOT a 
>> problem, I agree that there are no reasons to provide also an official gccgo 
>> version.
>> 
>> On Slack Markus asked to measure also the Init time but in all honesty I do 
>> not know how important is to provide also faster init time.
>> 
>> -- 
>> Michele Sciabarra
>> mich...@sciabarra.com
>> 
>> - Original message -
>> From: Carlos Santana 
>> To: dev@openwhisk.apache.org
>> Subject: Re: I created a variant of the go runtime that is faster at init 
>> time
>> Date: Tue, 11 Dec 2018 07:58:19 -0800
>> 
>> Let’s stick with the 1.11 stock compiler, produces greater portability abs
>> allows us to make updates to the base linux image with low risk for braking
>> an exec built previously
>> 
>> Not worth for the init, in general a busy app doesn’t suffer a lot of cold
>> start and on the flip side a infrequent app can leverage stemcell a/prewarm
>> 
>> I think if you want to investigate maybe opening an issue or start
>> discussion with go community on how the compiler can be improve if if their
>> flags that we are not using to optimized the binary
>> 
>> — Carlos
>> 
>> 
>> On Tue, Dec 11, 2018 at 7:46 AM David P Grove  wrote:
>> 
>>> 
>>> Sorry.
>>> 
>>> I mean do not bother providing a gccgo variant of the go runtime.  Stick
>>> with the official golang compiler at 1.11.   I don't see the small speedup
>>> in init time as being enough to justify supporting two variants of go
>>> actions.
>>> 
>>> --dave
>>> 
>>> 
>>> Michele Sciabarra  wrote on 12/11/2018 10:37:56 AM:
>>> 
>>>> From: Michele Sciabarra 
>>>> To: dev@openwhisk.apache.org
>>>> Date: 12/11/2018 10:38 AM
>>>> Subject: Re: I created a variant of the go runtime that is faster atinit
>>> time
>>>> 
>>>> Sorry not sure what you mean. Do you suggest I apply the change to use
>>>> gccgo in the official runtime, even if it is stuck at go 1.10 (the
>>>> latest is go 1.11) or I drop the idea of providing another runtime that
>>>> is faster to initialize? Would not be better to release both a gccgo
>>>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first
>>>> produces small

Re: I created a variant of the go runtime that is faster at init time

[Felix Meschberger]

Yes, a single contrib repository. I guess we still would want to lock it down 
but be more open to accept contributions, provided IP is properly transferred

Regards
Felix

> Am 12.12.2018 um 10:45 schrieb Bertrand Delacretaz :
> 
> Hi,
> 
> On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
>  wrote:
>> 
>> Indeed I was thinking to create a docker account  "openwhisk-contrib" to 
>> place those, let's say, unofficial images.
>> I am not sure who should own this account...
> 
> Accounts with "openwhisk" in their name should be owned by the
> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> Foundation - technically being donated as we speak IIUC but that
> doesn't make a real difference.
> 
> However what we are discussing here IMO is code repositories as code
> is what the ASF produces. I guess Felix's suggestion is to create one
> or a few openwhisk-contrib-* Git repositories under
> https://github.com/apache/ for such "contrib" modules.
> 
> -Bertrand

Re: I created a variant of the go runtime that is faster at init time

[Felix Meschberger]

Hi

From the sidelines…

I understand that there is limited bandwidth to support all sorts of runtimes 
.. But I wonder, whether such a thing would not have a space in some sort of an 
„unsupported“ contrib area ?

I myself like the idea of smaller binaries but wonder how you solve the dynmic 
linking issue of provisioning the dependency dynamic libraries in the container 
?

Regards
Felix

> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra :
> 
> I am perfectly fine if we do not provide a gccgo runtime, it was not a big 
> work, and I did it to see if it is possible to generate small executables 
> also for go, since the swift one is very small. 
> 
> Aside from the fact that actionloop-gccgo-v1.10  is the faster runtime both 
> in run and init time (a personal satisfaction) if the init time is NOT a 
> problem, I agree that there are no reasons to provide also an official gccgo 
> version.
> 
> On Slack Markus asked to measure also the Init time but in all honesty I do 
> not know how important is to provide also faster init time.
> 
> -- 
>  Michele Sciabarra
>  mich...@sciabarra.com
> 
> - Original message -
> From: Carlos Santana 
> To: dev@openwhisk.apache.org
> Subject: Re: I created a variant of the go runtime that is faster at init time
> Date: Tue, 11 Dec 2018 07:58:19 -0800
> 
> Let’s stick with the 1.11 stock compiler, produces greater portability abs
> allows us to make updates to the base linux image with low risk for braking
> an exec built previously
> 
> Not worth for the init, in general a busy app doesn’t suffer a lot of cold
> start and on the flip side a infrequent app can leverage stemcell a/prewarm
> 
> I think if you want to investigate maybe opening an issue or start
> discussion with go community on how the compiler can be improve if if their
> flags that we are not using to optimized the binary
> 
> — Carlos
> 
> 
> On Tue, Dec 11, 2018 at 7:46 AM David P Grove  wrote:
> 
>> 
>> Sorry.
>> 
>> I mean do not bother providing a gccgo variant of the go runtime.  Stick
>> with the official golang compiler at 1.11.   I don't see the small speedup
>> in init time as being enough to justify supporting two variants of go
>> actions.
>> 
>> --dave
>> 
>> 
>> Michele Sciabarra  wrote on 12/11/2018 10:37:56 AM:
>> 
>>> From: Michele Sciabarra 
>>> To: dev@openwhisk.apache.org
>>> Date: 12/11/2018 10:38 AM
>>> Subject: Re: I created a variant of the go runtime that is faster atinit
>> time
>>> 
>>> Sorry not sure what you mean. Do you suggest I apply the change to use
>>> gccgo in the official runtime, even if it is stuck at go 1.10 (the
>>> latest is go 1.11) or I drop the idea of providing another runtime that
>>> is faster to initialize? Would not be better to release both a gccgo
>>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first
>>> produces smaller binaries but it is a bit slower and it is stuck to go
>>> 1.10, the second is faster but it is slower to initialize because the
>>> executable is bigger.--
>>>  Michele Sciabarra
>>>  mich...@sciabarra.com
>>> 
>>> 
>>> 
>>> - Original message -
>>> From: David P Grove 
>>> To: dev@openwhisk.apache.org
>>> Subject: Re: I created a variant of the go runtime that is faster at
>>> init timeDate: Tue, 11 Dec 2018 10:17:51 -0500
>>> 
>>> Michele Sciabarra  wrote on 12/11/2018
>>> 07:23:14 AM:>
 Then I created a variant of the go runtime, using GccGo.  GccGo is a
 Go compiler, updated to Go version 1.10, that compiles using the Gcc
 compiler infrastructure. As a result, it produces dynamically linked
 executables that are smaller than the binaries produced by the
 standard Go compiler.
 ...
 
 GccGo is a bit slower than Go (but it is still the second faster
 runtime) but it is now the faster at init time because the
 executable is around 50k (and zipped it is only 17k).
 
 I am unsure if replace GccGo in the official runtime or provide
 both. The fact that the executable is small so it leads to faster
 init time I think it is important, but the  GccGo compiler it is a
 bit behind in term of language support.
 
>>> 
>>> My advice is to stick with the official runtime.  I think that is
>>> betterfor end users.
>>> 
>>> --dave
>>> 
>> 
> -- 
> Carlos Santana
> 

Re: Donation of ibm-functions/composer to Apache OpenWhisk

[Felix Meschberger]

Really great news, indeed.

I don‘t want to crush the party, but doesn‘t this have to go through the proper 
IP clearance [1] ? On the on hand OpenWhisk still is incubating but on the 
other hand this seems to be a substantial piece of code not part of the initial 
onboarding.

@Mentors, please advise.

Thanks
Felix

[1] https://incubator.apache.org/guides/ip_clearance.html

Von meinem iPad gesendet

Am 29.09.2018 um 03:09 schrieb rex f 
mailto:aug2...@gmail.com>>:

Thank you Oliver and team at IBM research. This looks fun to play with.

- rex fatahi, phd

On Fri, Sep 28, 2018 at 4:57 PM Olivier Tardieu 
mailto:tard...@us.ibm.com>> wrote:

Here is some context about composer.

Composer is a Javascript library to make it easy to author conductor
actions and build serverless micro services by composing OpenWhisk
actions. For now Composer is available at
https://github.com/ibm-functions/composer. There you will find not only
the code and documentation for Composer but also tutorials, videos, blog
posts, etc. Composer is also distributed as an npm package:
https://www.npmjs.com/package/@ibm-functions/composer/.

Conductor actions have been part of OpenWhisk since February 2018 (
https://github.com/apache/incubator-openwhisk/pull/3202). Like sequences,
conductor actions make it possible to chain the invocation of multiple
actions, but unlike sequences the length and components of the chain may
be decided at run time. In particular, conductor actions may implement
conditional, loops, and handle errors (whereas sequences abort on errors).
Conductor actions are documented in

https://github.com/apache/incubator-openwhisk/blob/master/docs/conductors.md
.

While conductor actions are powerful, writing conductor action code can be
tedious. The Composer library dramatically simplifies the task of writing
conductor actions. Conditional control flow for instance may be expressed
as follows:

composer.if(?authenticateRequest?, ?processRequest?, ?rejectRequest?)

In this example, a first action validates a request, then if the request
is admissible it forwards the request to a second action named
processRequest. If not, it invokes the rejectRequest action instead. The
Composer library automatically synthesizes the code of a conductor action
that implements this flow of control. processRequest may be implemented in
Javascript, rejectRequest in Python, and authenticateRequest may come from
a third-party. There is no restriction on what the composed actions can
be.

The development of Composer actually predates conductor actions by almost
a year. We (IBM Research) open sourced the first Composer library in
October 2017. We later developed conductor actions as a low-level,
language-independent runtime mechanism to dynamically chain action
invocations and rewrote Composer (v2) to take advantage of conductor
actions.

Today?s Composer is a Javascript library focused on building sequential
compositions of actions. But we don?t intend to stop there. In particular,
we are already working on Composer for Python and on parallel composition.
We think that Composer will be an important asset for OpenWhisk and, with
the help of the community, we hope to accelerate its development.

You can always find me on the OpenWhisk dev list or on slack.

Olivier



From:   "David P Grove" mailto:gro...@us.ibm.com>>
To: dev@openwhisk.apache.org
Date:   09/28/2018 12:56 PM
Subject:Donation of ibm-functions/composer to Apache OpenWhisk





IBM Research would like to donate the Composer code in
ibm-functions/composer to the Apache OpenWhisk incubator project.  The
code
is already open source under the Apache 2.0 license.

Unless there are objections raised here on the dev list, I will plan to
submit the infra tickets on Monday to create an
apache/incubator-openwhisk-composer git repo, enable Travis on it, etc.
and
we will migrate the code next week.

--dave

Re: How to pass size the max size of the request to the runtime?

[Felix Meschberger]

Hi

Holding the complete input in memory ? Sounds like a good DoS surface - unless 
you limit the input size

Regards
Felix

--
Creative typing support courtesy of my iPhone

Am 11.09.2018 um 15:02 schrieb Rodric Rabbah 
mailto:rod...@gmail.com>>:

The http post will have a content length is that useful?

-r

On Sep 10, 2018, at 7:45 AM, Michele Sciabarra 
mailto:mich...@sciabarra.com>> wrote:

Hello, I am in the process of running the mandatory tests against the Go 
Runtime.
In the process, I fixed a lot of bugs, because those tests revealed a number of 
details about encoding, env variables and other things that were not obvious to 
me in the first place.

Now I have a problem: I am trying to pass the test that tried to send a 
one-megabyte big request to the runtime.
Currently, it does not work because I discovered the "scan" buffer has in 
Golang a fixed size of 64k.

Of course, I can increase it but I need to know how big it must be. I know that 
you can set some parameters at OpenWhisk level but I am not aware how a runtime 
can know those parameters. Most notably I need to be able to read the maximum 
size of the requests because I need to allocate a buffer at init time. Any 
hints?


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

Re: Adding pages to confluence

[Felix Meschberger]

Hi Tyson

I have granted you write access

Regards
Felix

> Am 30.06.2017 um 18:03 schrieb Tyson Norris :
> 
> Hi -
> I’m trying to add a page to 
> https://cwiki.apache.org/confluence/display/OPENWHISK/Proposals
> But it seems like I don’t have permission?
> 
> Should I instead add it to GitHub at 
> https://github.com/apache/incubator-openwhisk/wiki ?
> 
> Thanks
> Tyson

Re: Forwarding updates from Wiki to commits@ ? (was: OpenWhisk, Kubernetes, what was learned and where we would like to go next.)

[Felix Meschberger]

Hi Carlos

Thanks for confirming.

Regards
Felix

> Am 10.06.2017 um 16:59 schrieb Carlos Santana <csantan...@gmail.com>:
> 
> I can validate that it works, I received a couple of emails this morning :-)
> 
> This is also useful to get notifications on any updates to our wiki
> 
> - Carlos Santana
> @csantanapr
> 
>> On Jun 10, 2017, at 10:48 AM, Felix Meschberger <fmesc...@adobe.com.INVALID> 
>> wrote:
>> 
>> Hi all
>> 
>> Ok, I have implement this openwhisk-commits user and written it up here: 
>> https://cwiki.apache.org/confluence/display/OPENWHISK/Forward+Wiki+Changes+to+Commits+List
>> 
>> Regards
>> Felix
>> 
>> Am 08.06.2017 um 16:49 schrieb Matt Rutkowski 
>> <mrutk...@us.ibm.com<mailto:mrutk...@us.ibm.com>>:
>> 
>> Hi Felix,
>> 
>> I think it would be a very good idea to forward CWIKI updates to the
>> "commits" list.
>> 
>> Kind regards,
>> Matt
>> 
>> 
>> 
>> 
>> From:   Felix Meschberger 
>> <fmesc...@adobe.com.INVALID<mailto:fmesc...@adobe.com.INVALID>>
>> To: "dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org>" 
>> <dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org>>
>> Date:   06/08/2017 02:52 AM
>> Subject:Forwarding updates from Wiki to commits@ ? (was:
>> OpenWhisk, Kubernetes, what was learned and where we would like to go
>> next.)
>> 
>> 
>> 
>> Hi all
>> 
>> This question by Ben on this list
>> 
>> Also, would you prefer discussion via comments on the wiki page or here
>> on
>> the dev list?
>> 
>> triggers the following proposal: How about configuring the wiki such that
>> changes to the wiki are forwarded to the commits@ list ?
>> 
>> (Technically this can be done with a technical user whose EMail Address is
>> commits@ and which is subscribed to wiki updates)
>> 
>> Thoughts ?
>> 
>> Regards
>> Felix
>> 
>> 
>> 
>> 
>> 

Re: Forwarding updates from Wiki to commits@ ? (was: OpenWhisk, Kubernetes, what was learned and where we would like to go next.)

[Felix Meschberger]

Hi all

Ok, I have implement this openwhisk-commits user and written it up here: 
https://cwiki.apache.org/confluence/display/OPENWHISK/Forward+Wiki+Changes+to+Commits+List

Regards
Felix

Am 08.06.2017 um 16:49 schrieb Matt Rutkowski 
<mrutk...@us.ibm.com<mailto:mrutk...@us.ibm.com>>:

Hi Felix,

I think it would be a very good idea to forward CWIKI updates to the
"commits" list.

Kind regards,
Matt




From:   Felix Meschberger 
<fmesc...@adobe.com.INVALID<mailto:fmesc...@adobe.com.INVALID>>
To: "dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org>" 
<dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org>>
Date:   06/08/2017 02:52 AM
Subject:Forwarding updates from Wiki to commits@ ? (was:
OpenWhisk, Kubernetes, what was learned and where we would like to go
next.)



Hi all

This question by Ben on this list

Also, would you prefer discussion via comments on the wiki page or here
on
the dev list?

triggers the following proposal: How about configuring the wiki such that
changes to the wiki are forwarded to the commits@ list ?

(Technically this can be done with a technical user whose EMail Address is
commits@ and which is subscribed to wiki updates)

Thoughts ?

Regards
Felix

Forwarding updates from Wiki to commits@ ? (was: OpenWhisk, Kubernetes, what was learned and where we would like to go next.)

[Felix Meschberger]

Hi all

This question by Ben on this list

> Also, would you prefer discussion via comments on the wiki page or here on
> the dev list?

triggers the following proposal: How about configuring the wiki such that 
changes to the wiki are forwarded to the commits@ list ?

(Technically this can be done with a technical user whose EMail Address is 
commits@ and which is subscribed to wiki updates)

Thoughts ?

Regards
Felix

Re: Red Hat and Apache OpenWhisk

[Felix Meschberger]

Absolutely. And maybe also in the community development section of the board 
report ?

Regards
Felix

Am 31.05.2017 um 23:38 schrieb Andreas Nauerz 
>:

Hey Ben et al,

welcome on board.

By the way:
If someone from RedHat sends me a logo I can add it to here asap: 
 http://openwhisk.org/supporters
I also think it may make sense to inform the world about this collaboration via 
a short blog post to be added under our medium.com channel: 
https://medium.com/openwhisk - thoughts?

Thanks.
Mit freundlichen Grüßen / Kind regards

Dr. Andreas Nauerz

Technical Product Manager |Master Inventor | Member TEC Central Region
IBM Cloud, Bluemix



Phone:  +49-7034-643-2954IBM Deutschland

E-Mail: andreas.nau...@de.ibm.com  
Schoenaicher Str. 220
 71032 Boeblingen
 Germany



IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: 
Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294





From:"Daniel Krook" >
To:dev@openwhisk.apache.org
Date:31/05/2017 23:33
Subject:Re: Red Hat and Apache OpenWhisk




Excellent news! Welcome!


> From: Ben Browning
> Subject: Red Hat and Apache OpenWhisk
>
> My name is Ben Browning and I lead the Serverless and
> Function-as-a-Service engineering team at Red Hat. After much
> research, evaluation, and internal discussion I'm pleased to announce
> that we've decided to refocus our own Serverless efforts from the
> Funktion project (https://funktion.fabric8.io/) to Apache OpenWhisk.
>
> We look forward to filing issues, creating pull requests,
> participating in dev discussions, giving conference talks, and
> contributing however we can to ensure Apache OpenWhisk's continued
> success.
>
> Thanks for all your hard work that makes my job so much easier!
>
> Ben


Daniel Krook
http://krook.info/

Re: Red Hat and Apache OpenWhisk

[Felix Meschberger]

Great news ! Thanks, Ben for sharing and welcome to here.

Looking forward to your and your team’s contributions.

Regards
Felix

> Am 31.05.2017 um 22:59 schrieb Ben Browning :
> 
> My name is Ben Browning and I lead the Serverless and
> Function-as-a-Service engineering team at Red Hat. After much
> research, evaluation, and internal discussion I'm pleased to announce
> that we've decided to refocus our own Serverless efforts from the
> Funktion project (https://funktion.fabric8.io/) to Apache OpenWhisk.
> 
> We look forward to filing issues, creating pull requests,
> participating in dev discussions, giving conference talks, and
> contributing however we can to ensure Apache OpenWhisk's continued
> success.
> 
> Thanks for all your hard work that makes my job so much easier!
> 
> Ben

Re: [INFRA-13014] openwhisk.io transfer

[Felix Meschberger]

Thanks, Carlos and Matt

Glad it’s being taken care of.

Regards
Felix

> Am 30.05.2017 um 17:20 schrieb Carlos Santana <csantan...@gmail.com>:
> 
> The domain that IBM/Andreas owns is openwhisk.org not openwhisk.io
> 
> I think that ASF don't want to be in business of owning the burden of a $60
> monthly bill to pay for openwhisk.org domain name registration.
> 
> My interpretation of the INFRA issue is that we need to redirect
> openwhisk.org to openwhisk.incubator.apache.org
> 
> We will do the a redirect once we have the webstite deploy via Jenkins to
> openwhisk.incubator.apache.org which I created an INFRA ticket for this
> work.
> 
> I will update the INFRA ticket 13014
> 
> --Carlos
> 
> 
> On Tue, May 30, 2017 at 8:10 AM Matt Rutkowski <mrutk...@us.ibm.com> wrote:
> 
>> I believe that Daniel Krook and Andreas are the only two people who have
>> been updating the site for the last many months and both have been busy on
>> other topics and hav enot had a chance to look at moving to use a Jenkins
>> build hosted by INFRA (to generate the site).
>> 
>> Kind regards,
>> Matt
>> 
>> 
>> 
>> 
>> From:   Felix Meschberger <fmesc...@adobe.com.INVALID>
>> To: "d...@openwhisk.incubator.apache.org"
>> <d...@openwhisk.incubator.apache.org>
>> Date:   05/30/2017 02:55 AM
>> Subject:[INFRA-13014] openwhisk.io transfer
>> 
>> 
>> 
>> Hi all
>> 
>> We have INFRA-13014 [1] regarding the transfer of the openwhisk.io site.
>> 
>> Is there someone on the team working on this topic ?
>> 
>> Thanks
>> Felix
>> 
>> [1] https://issues.apache.org/jira/browse/INFRA-13014
>> 
>> 
>> 
>> 
>> 
>> 

Re: Coming to ApacheCON? Showcase your project at a Podling Shark Tank!

[Felix Meschberger]

Thanks for taking the stab ! This will be great.

In all honesty, though, I think it was @Trevor who succeeded adding you, Carlos.

Regards
Felix

> Am 19.04.2017 um 17:59 schrieb Carlos Santana :
> 
> Gracias Matt and Felix
> On Wed, Apr 19, 2017 at 11:39 AM Matt Rutkowski  wrote:
> 
>> Thanks for adding us Felix...  it is/was an ACL issue.
>> 
>> 
>> 
>> 

Re: OpenWhisk Functions to receive GitHub pull request updates on Slack

[Felix Meschberger]

Hi Priti

This sounds interesting, indeed.

Unfortunately it seems that your URLs point to a restricted/private repository 
which is not readily accessible.

I suggest you create an issue for the appropriate openwhisk repository, 
probably https://github.com/openwhisk/openwhisk-playground and attach a 
pull-request. Important is that the JS files have the Apache-required license 
header.

Regards
Felix


Am 09.02.2017 um 11:08 schrieb Priti Desai 
>:


Hi,

I was working on some functions that uses OpenWhisk and had an idea to add
it as a package. Here is its description:

This package is about demonstrating how OpenWhisk project developers are
using OpenWhisk functions to
improve its own Continuous Development and Integration (CD/CI) processes.
OpenWhisk development and code commits are managed by Pull Requests in
GitHub. OpenWhisk team at IBM has implemented set of functions to receive
updates on Slack when a GitHub Pull Request is ready to merge or a list of
requests are under review for certain days and haven’t merged.

Please grant your permission to create a new package and commit the list of
files from:

https://github.ibm.com/bjustin/OWGitSlackBot/blob/master/find_delayed_prs.js
https://github.ibm.com/bjustin/OWGitSlackBot/blob/master/monitor.js
https://github.ibm.com/bjustin/OWGitSlackBot/blob/master/post_to_slack.js

Cheers
Priti

Re: Introducing Priti Desai

[Felix Meschberger]

Hi Priti

Pleased to meet you and welcome to the party !

For starters I suggest you subscribe to the list sending mail to 
dev-subscribe(at)openwhisk(dot)apache(dot)org

Regards
Felix

> Am 09.02.2017 um 10:59 schrieb Priti Desai :
> 
> 
> 
> Hello all,
> 
> My name is Priti Desai. I have been working on OpenWhisk project since
> April 2016. I first started evangelizing OpenWhisk by blogging about its
> architecture, deployment, and its real world use cases. Now, I would like
> to be part of the team and contribute some code to the project.
> 
> I joined IBM in September 2015 and was an OpenStack contributor before
> moving onto OpenWhisk. As an OpenStack engineer, I specialized in IAC
> (Identity and Access Control) and Security.
> 
> Outside of my day job at IBM, I am an Art Entrepreneur, designing and
> decorating homes with hand painted custom fine art.
> 
> I am very excited and looking forward to be part of OpenWhisk family.
> 
> Cheers
> Priti

Re: CLA Status

[Felix Meschberger]

Hi Taylor

pleased to meet you and looking forward to your submissions.

As for the CLA: I do not see it recorded yet. When did you send it in ?

Regards
Felix

> Am 30.01.2017 um 19:36 schrieb Taylor King :
> 
> 
> 
> Hi everyone,
> 
> My name is Taylor King, I've been working with Jeremy Geddes on adding some
> more security policies to the OpenWhisk API Gateway. I have submitted my
> CLA a couple of times, both by postal service and GPG signed via email. I
> still haven't heard anything back from apache.
> 
> Thanks,
> Taylor King

Re: openwhisk-devtools does not start on Mac

[Felix Meschberger]

Hi Carlos

Thanks. Yes, there seems to be a mismatch, hence 
https://github.com/openwhisk/openwhisk-devtools/issues/4

Whatever we do going forward — keep the current Consul based setup (all but 
devtools) or move to simple properties file (devtools) — I think we should make 
sure to have a consistent setup working out-of-the-box for quick/simple testing.

Thanks
Felix


Am 27.01.2017 um 02:57 schrieb Carlos Santana 
<csantan...@gmail.com<mailto:csantan...@gmail.com>>:

Hi Felix I didn't want to leave this email thread hanging out here as
unresponsive from the community.

It looks like you got it working following Vagrant flow from the main repo.

I think there was a recent change around setting up keys on deployment that
it's currently handle in all installation methods (mac, ubuntu, vagrant,
Travis ) but maybe is not reflected on docker-compose flow in the dev tools
repo.

-- Carlos

On Wed, Jan 25, 2017 at 5:19 AM Felix Meschberger 
<fmesc...@adobe.com<mailto:fmesc...@adobe.com>>
wrote:

Hi

digging along it looks like the OpenWhisk controller is actually not
starting.

Where the log file then says:

[2017-01-24T18:08:18.043Z] [INFO] [??] [WhiskConfig] reading properties
from consul at consul.docker:8500
[2017-01-24T18:08:20.989Z] [WARN] [??] [WhiskConfig] failed to read
properties from consul: null
[2017-01-24T18:08:21.011Z] [ERROR] [??] [Config] required property
whisk.system.key still not set


Woot ! No properties from consul. I think this is fine, right ?

But where do I get the whisk.system.key ?

Thanks
Felix

Am 24.01.2017 um 16:02 schrieb Felix Meschberger 
<fmesc...@adobe.com<mailto:fmesc...@adobe.com>>:

Hi

I am trying to run the docker-compose setup of the
openwhisk/openwhisk-devtools repository. It builds fine and starts
launching the containers. But it waits indefinitely for the openwhisk
controller to start while consul fails to connect to port :

2017/01/24 15:01:15 [WARN] agent: http request failed '
http://172.18.0.9:/ping': Get http://172.18.0.9:/ping: dial tcp
172.18.0.9:: getsockopt: connection refused

I am running on macOS Sierra with Docker 1.13.0.

Could it be docker on mac being the problem ?

Thanks
Felix

Re: Contributor intent

[Felix Meschberger]

Hi Vinay

There is no formal enrollment. Just subscribe to this list (send mail to 
dev-subscribe@...), participate in the discussions, download the code, provide 
patches, etc. As you please.

This being a meritocratic project, you will eventually get an invitation to 
become a committer provided you are active and help the community. 

Regards
Felix

Von meinem iPad gesendet

> Am 21.01.2017 um 11:58 schrieb Vinay :
> 
> A gentle reminder 
> 
> Regards
> Vinay
> Sent from my iPhone
> 
>> On 18 Jan 2017, at 17:32, Vinay  wrote:
>> 
>> Hello there 
>> 
>> I evangelise the Serverless value propositions to many of my customers in 
>> Europe. I also am a member of oasis TOSCA committee.
>> Would like to be a contributor to the openehisk project.
>> 
>> I need to know the procedure to enroll pls
>> 
>> Regards
>> Vinay
>> Sent from my iPhone

Re: some messages from @adobe going to spam?

[Felix Meschberger]

Hi

I have internally forwarded a instance of such a case.

If you also have such a case, feel free to forward me the complete headers 
off-list.

Thanks
Felix


> Am 18.01.2017 um 20:35 schrieb Carlos Santana <csantan...@gmail.com>:
> 
> Thanks for pointing this out, I found the missing emails in my spam (I'm
> also using google inbox/gmail)
> 
> 
> On Thu, Jan 12, 2017 at 12:40 AM Felix Meschberger <fmesc...@adobe.com>
> wrote:
> 
>> Hi Rodric and Stephen
>> 
>> Adobe recently enabled DMARK which might cause failures as signatures of
>> message headers fail to validate as list servers add/change headers.
>> 
>> Can you please forward these erroneous mails to me off-list ?
>> 
>> Thanks
>> Felix
>> 
>> Von meinem iPad gesendet
>> 
>>> Am 11.01.2017 um 22:57 schrieb Stephen Fink <fink.step...@gmail.com>:
>>> 
>>> I can confirm — I’ve experienced the same problem (gmail moving to spam).
>>> 
>>>> On Jan 11, 2017, at 4:55 PM, Rodric Rabbah <rod...@gmail.com> wrote:
>>>> 
>>>> here's a screenshot if it's helpful - turns out I've missed at least 4
>> emails to dev list so far.
>>>> 
>>>> -r
>>>> 
>>>> 
>>>> On Wed, Jan 11, 2017 at 4:53 PM, Rodric Rabbah <rod...@gmail.com
>> <mailto:rod...@gmail.com>> wrote:
>>>> I inadvertently found out I missed two replies to the dev list from
>> Dragos and Michael when Matt responded to the same thread. I checked my
>> spam folder and gmail claims the two messages were marked as spam because:
>> "It has a from address in adobe.com <http://adobe.com/> but has failed
>> adobe.com <http://adobe.com/>'s required tests for authentication."
>>>> 
>>>> I'm not sure if there's anything to be done about this on Adobe's side
>> - seems odd to me. But heads up to others who might have a similar issue
>> and might be missing replies.
>>>> 
>>>> -r
>>>> 
>>> 
>> 

Re: Allow actions to be accessible from a web browser

[Felix Meschberger]

Hi Rodric

Am 13.01.2017 um 18:07 schrieb Rodric Rabbah 
>:

you mean the property really indicates the Content-Type to represent the
resource as ? Have you considered using the an extension in the action such
as …/my-action.html ?

I had not. Do you mean an extension to describe both the content type and
the field to project? There are two parts to this from the demo (and what I
implemented):

1: projecting a field from the JSON object that is the result of the
action.
2: how to marshal the projected value

So I conflated both: the property name implies also a convention for the
marshaling. So using html reads response.html and turns it into the proper
format.

Yeah, that is problematic and limiting indeed. As the property to represent and 
the format to represent it in are orthogonal issues and thus cannot possibly be 
conflated unless you come up with a complex encoding.


Your suggestion I think makes it possible to disentangle the desired
content-type and the property name to project. It could also then make it
possible to do what Nick alluded to: rather than projecting one property,
the resource could be specified as a full path (of nested properties). As
in:

http://openwhisk.host/experimental/web/ns/p/action.html/a/b/c.

One issue with using "." as the separator is that it's also a legal
character for action names. So a different delimiter would be needed
otherwise the path parsing is ambiguous.

I like that. And incidnentally (or not, maybe, probably) this is exactly how we 
disect URL paths in Apache Sling: See URL Decomposition [1]

This also solves the „action is allowed to contain a dot“ problem.

Regards
Felix

[1] 
http://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

Re: Allow actions to be accessible from a web browser

[Felix Meschberger]

Hi

Sounds like a great idea … and I really like the demo video !

As for the status codes, I would probably prefer 404/Not Found for non-existing 
actions rather than 400/Bad Request. And 404 as well for the case of the action 
not being available anonymously.

And concluding from the demo by „projecting based on a named property“ you mean 
the property really indicates the Content-Type to represent the resource as ? 
Have you considered using the an extension in the action such as 
…/my-action.html ? Missing support for the requested content type could be 
406/Not Acceptable (or also 404/Not Found).

Regards
Felix


> Am 12.01.2017 um 23:44 schrieb Rodric Rabbah :
> 
> I just opened a pull request to allow actions to be accessible viaa  web
> browser. Action invokes this way are anonymous in that the caller is not
> authenticated. The intended action must be named in the path as a fully
> qualified name as in
> /experimental/web/some-namespace/some-package/some-action. The package is
> optional in that the action may be in the default package. In which case,
> the string "default" must be used.
> 
> If the action doesn't exist (or the namespace is not valid) a BadRequest is
> generated. Optionally, the result form the action may be projected based on
> a named property. As in
> /experimental/web/some-namespace/some-package/some-action/some-property. If
> the property
> does not exist in the result then a BadRequest is generated. By convention,
> the "html" property will attempt to respond with media type "text/html".
> 
> Actions may be exposed to this web proxy by adding an annotation ("export"
> -> true).
> Demo video https://ibm.box.com/s/5c6ignvejihbai3f59uvqcxee9etf0lf.
> 
> Feedback solicited and welcomed.
> 
> -r

Re: Testing commits mailing list

[Felix Meschberger]

Got the it 

Regards
Felix

Von meinem iPad gesendet

> Am 12.01.2017 um 19:02 schrieb Carlos Santana :
> 
> This is just a test to see if the mailing list is enable and I  can post to it
> 
> --Carlos

Re: Browsing the mailing lists and hostnames

[Felix Meschberger]

Hi

Me thinks that „officially“ it is (a)openwhisk.incubator.apache.org. But 
(a)openwhisk.apache.org does work as well, probably due to how DNS and the 
mailing list manager is configured.

Regards
Felix

> Am 11.01.2017 um 21:19 schrieb Carlos Santana :
> 
> I have sent to both and receive from both, so my assumption they are aliases
> 
> -- Carlos
> 
> On Wed, Jan 11, 2017 at 9:48 AM Rodric Rabbah  wrote:
> 
> Carlos are these two aliases: @openwhisk.apache.org and @
> 
> openwhisk.incubator.apache.org? So one can send email to either?
> 
> 
> 
> -r

Moving forward with repositories

[Felix Meschberger]

Hi all

Given misunderstandings on what it means to be able to stay on GitHub we are 
not ready yet to transfer repositories from the GitHub OpenWhisk organisation 
to the GitHub Apache organisation thereby renaming the repositories according 
to the naming conventions.

The inhibitors for moving quickly basically are:
 - Custom developer processes for pull requests
 - A number of business critical CI/CD processes

Particularly reconfiguring the CI/CD process will take some time.

Yet, we understand the desires and policies of ASF to properly manage the 
source code repositories. 

In the interest of moving forward, the proposed high level plan is:

 (0) Create a documentation page on commit and contribue processes
 (as proposed by Matt along the lines of Cordova’s Contributor
 Guidelines [1])
 (1) Transfer the repositories to the Apache GitHub organisation
 and setup required mail notifications for commits/pull requests
 and issue updates
 (2) Fork the apache/incubator-openwhisk-* repositories to the
 OpenWhisk organization under their previous names:
 (2a) Repositories are read-only
 (2b) Repositories are synced from their fork source

User processes have to be adapted as soon as the repositories have been 
transferred.

Technical process should be adapted to the new processes within 3 weeks from 
the transfer of the repositories (unforeseen difficulties to be discussed).

With the transfer the wikis and issues are transferred as well. For Wikis this 
is not a big deal. For issues, there are two things to consider:

  (a) how do we deal with bots reacting to issue events ?
  (b) how do we deal with Zenhub boards ? Can we live without them for a moment 
?

Ideally we would start implementing this plan over the holidays so that 
repositories are ready and in place after that. According to Greg Infra is 
staffed to work on this.

@Greg: Would it be an option to have the read-only forks in the old locations 
for a certain time ? Markus Thoemmes is an admin of the current repositories 
available this week.

@Project: Would that work for you ?

@Markus Thoemmes: May I ask you to work with Greg to do the necessary ?

Regards
Felix

[1] http://cordova.apache.org/contribute/contribute_guidelines.html