remove rotted distributed playbooks?

The OpenWhisk repo includes a number of playbooks for setting up a distributed openwhisk deployment, including provisioning and setup of VMs. The instructions and playbooks have not been touched - for the most part - since their introduction, are untested, and have already various bits of rot. I

Re: concurrency tracking PR

I can give it a look this afternoon although Chetan's review looks thorough and the tests look good to me. I'll scrutinize them a bit more. -r On Wed, Jan 30, 2019 at 10:18 AM Tyson Norris wrote: > Hi – > I have a PR #4186 ready to merge that has some changes to critical areas > of

Re: OpenWhisk & Knative

Thanks for the question. There are several people from the openwhisk community who are immersed in the knative community, including lots of folks from Red Hat and IBM. I'll trust they will chime in as they see fit. (Aside: The question has been posed to me often enough that it's worth putting

Re: [discuss]Add protect feature to avoid update or delete actions by mistake

I posted a comment on the issue but for the benefit of the dev list: I think the implementation points to a more general permission set on an action. In the noted PR, it is strictly a "write" permission for the namespace (like a group in UNIX terminology), and one can image an execute permission

Re: time for next OpenWhisk release wave?

> We probably should also create an umbrella issue in the release-repo with a > checklist or something to list all the repos we are releasing, what > release/voting wave they are going in, and how is responsible for deciding > they are ready. Or we could do the overall planning in the wiki.

Re: time for next OpenWhisk release wave?

Following up on this after watching today's community call replay. Dave made the point that the big chunk of work toward this release is writing release notes and deciding which of the components is ready. Several people volunteered (Carlos, Matt) and I’m volunteering myself as well. I’d

Re: Openwhisk-user-events repository

Cosmin, welcome! And thank you for the presentation today which I just watched on replay. This is great to see and I think a huge addition to openwhisk. OpenFaaS I think did a pretty good job early on of integration metrics like this with the service and I’ve seen that resonate quite well with

Re: time for next OpenWhisk release wave?

i like it. On Mon, Jan 7, 2019 at 10:03 PM David P Grove wrote: > > > I would like to see us push out a consolidated next release in the near > future (by end of January?). I'd also like to see us attempt to establish > a regular cadence of such consolidated releases (perhaps quarterly?). > >

Re: Are changes to the ActionLoop required to implement the Pyhton runtime?

Can you give some examples Michele? The errors checked in the test are to give the user some indication of what failed (parse error, missing variable definition, ...) - is the proxy you're working on able to report these errors? i dont think the exact wording matters but the nature of the content

Re: publishing developer-oriented binary artifacts

Thanks Dave for consolidating the various points of discussion. This is very helpful and the thoughtful recommendations. I agree on all parts with your assessment and direction, and will help out on driving the releases so we can get to a more cogent point. -r > On Dec 12, 2018, at 9:16 AM,

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

+1 “I think it would be better to organize around 1 git repo per language.” -r > On Dec 12, 2018, at 9:21 AM, David P Grove wrote: > > For the runtimes specifically, if it is technically feasible I think it would > be better to organize around 1 git repo per language. > > That repo could

Re: Staging environment servers

Is that outdated? Per [1] Adobe Inc. contributed a donation toward infrastructure and now Vincent and others are working on enabling Jenkins on those machines. Do we need more machines? -r [1]

Re: Autonomous Container Scheduler v2 proposal

Thanks for sharing Dominic. I'll need to read this slowly to understand it. It does look like a bit of the proposal you've discussed in the past with 1 topic per action name (per namespace). Have you seen this scale in your production to thousands of topics? -r On Wed, Nov 28, 2018 at 5:59 AM

Re: Relieve CouchDB on high load

ivations have been written in the > current minute. The remaining quota is passed on. On trying to save an > activation (of a trigger, a sequence or an activation) this quota is > checked and only saved, if it is above 0. > > Greetings > Christian > > Am Mi., 24. Ok

Re: Don't differentiate between blackbox and whitebox images

I think it would be a mistake to blindly merge two container pools - docker actions as run today are pulled as needed and can take a long time, they’re subject to different kinds of attacks, and can affect performance of other tenants (higher noisy neighbors). If you want to allow more

Re: Change the package name into org.apache.openwhisk for openwhisk modules

Thanks Shawn for following up. This makes sense to me. We’ll need to add some travis integration into the repo to run the tests, and push the image to dockerhub. Then we can open a PR against Openwhisk to add the new runtime to the manifest and update some docs. -r > On Nov 27, 2018, at 11:53

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

[x] +1 Release as Apache OpenWhisk 0.9.0-incubating: openwhisk composer 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. (Doesn’t really

Re: donation of Python composer library

fantastic new addition! -r On Tue, Nov 20, 2018 at 1:18 PM David P Grove wrote: > > > IBM would like to donate a Python composer library to the Apache OpenWhisk > project. The code was recently open-sourced under the Apache v2 license > at https://github.com/ibm-functions/composer-python/. >

Re: The ActionLoop based runtime for Python3.6 for OpenWhisk is 5 times faster than the current runtime

Improving the performance of the proxy is generally good. I noticed your perf numbers show the action has a high latency (49ms). I checked my laptop (which is an older generation mac) and for node, I get micro-sec latency. We should level set on the baselines. -r On Sun, Nov 18, 2018 at 8:09 AM

Re: An actionloop runtime for NodeJS is 86 request/sec but I cannot measure performances for current runtime

Hi Michele There's some discussion on slack regarding this question. The node runtime by default will not permit more than one /run call at a time. The work that Tyson recently concluded does relax this. I did however run the node runtime locally using the echo.js action, and get very different

Re: How to best run non-local tests in ASF (was: Performance tests for OpenWhisk)

Thank you Adobe Inc and the Adobe team for the donation and making it possible to have infra for the project! And thanks Carlos for also pushing this forward. -r > On Nov 7, 2018, at 2:25 PM, Carlos Santana wrote: > > We got the 3 VMs Woot !! > it only took 6 months > > The INFRA ticket [1]

Re: A question about concurrency in OpenWhisk

Today there is at most one activation at a time per container we. A PR from Tyson will allow a runtime to opt into intro container concurrency and so the invoker will send up to N invocations to that the container when possible. https://github.com/apache/incubator-openwhisk/pull/2795 -r > On

Re: [long] I need help to find an issue with the Go runtime that I cannot track down

I’m wondering why the “basic” runtime unit tests didn’t catch the lack of flush (this same symptom was observed during the dev of C# runtime and I thought the unit tests flagged it). Maybe we need a tighter tests with two invokes. -r > On Oct 28, 2018, at 7:47 AM, Michele Sciabarra wrote: >

Re: Completing the integration of the Go lang runtime

"go" for it! I'll look forward to reviewing it. -r On Fri, Oct 26, 2018 at 1:40 PM Michele Sciabarra wrote: > Hello all, > > Carlos today opened the final issue to complete the integration of the > Golang runtime in OpenWhisk > > https://github.com/apache/incubator-openwhisk/issues/4085 > >

Re: Relieve CouchDB on high load

Thanks for the additional information Christian - I took a look at the PR and added a few comments. I think you can approach this as another quota (number of activations stored per minute or per hour) and setting the quota to 0 would disable all stores. I also don't like the way this was done in

Re: Relieve CouchDB on high load

Markus, Christian - it's not clear to me from the first note if Christian is proposing excluding all activation data (including the metadata, not just the logs) from couchdb, for a namespace. I think this is a very crude patch and wonder why we don't address the underlying issue instead. I haven't

Re: JIRA feed package for Openwhisk

Fantastic! Thanks for sharing, I’ll have a look. I wonder if we can use this to automate Jira flows with OpenWhisk in the future. -r > On Oct 17, 2018, at 2:16 AM, Prabhash Rathnayake > wrote: > > Hi all, > I have developed a JIRA package for Openwhisk and planing to send a PR to > the

Re: Logstore usage during `activation get`

> By "break this" do you mean at some point we should remove the logs from the GET? Yes. @dubee thoughts? Since you've worked on the elastic plugin. -r

Re: Logstore usage during `activation get`

Hi Tyson - this was the intent of the API design: there is a separate resource for LOGS and the RESULT. The reasoning also that the metadata is typically small but the logs could be much larger. Separating the two was also intended for easier streaming of the responses. Because of

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

Thanks you Felix. There are five contributors. Of those, the four contributors from IBM already have Apache CLAs on file: Olivier Tardieu, Nick Mitchell, Kerry Chang and Rodric Rabbah. There is one commit - a small typo fix to documentation - https://github.com/ibm-functions/composer/pull/23

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

Fantastic! -r > On Sep 28, 2018, at 12:56 PM, David P Grove wrote: > > > > 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

Re: Official Swag store for OpenWhisk

Should we include a link on the webpage? -r > On Sep 27, 2018, at 10:23 AM, Carlos Santana wrote: > > I worked today with Mark T at ApacheCon to get Apache comdev swag store > enable for OpenWhisk > > https://www.redbubble.com/people/comdev/works/34185110-apache-openwhisk > > —Carlos > -- >

Re: Proposal to Remove Artifact Store Polling for Blocking Invocations

Thanks James for the explanation and patches. It sounds like there should be two separate PRs, one to address the bug and the other to remove polling. What do you think? -r > On Sep 21, 2018, at 1:09 PM, James W Dubee wrote: > > > > > > Hello OpenWhisk developers, > > When a blocking

Re: Is it me or there is a bug in the mandatory tests?

e variables are not passed by the withContainer(env.toMap) in which > other way are the enviroment variables are sent to the runtime? > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Rodric Rabbah > To: dev@openwhisk.ap

Re: Is it me or there is a bug in the mandatory tests?

it's not a bug in that the API host is provided as an environment variable at container startup. so the data passed into the container at /run does not include the environment variable (today). -r On Tue, Sep 11, 2018 at 7:09 PM Michele Sciabarra wrote: > This is a separate issue related to

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

elix 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

Re: A problem in changing the signature of the action for the Golang runtime

Hey Michele The particular test you mention has a bypass feature for languages which prevent you from returning invalid json (statically typed ones). You can set the skip flag for the test and you’re done. The swift runtime does this for example. In java I also skipped this test but added a

Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache

> ... we will very quickly have runtimes having Apache releases on their own cadence and the version numbers won't align with each other or with openwhisk core. We have to fully realize this now --- otherwise, as I stated earlier, I don't see what we've gained from splitting the one repo into so

Re: Prototyping for a future architecture

Thanks Michael for raising these points. I share the same opinion and sentiment and think a branch with a clean migration story is better and makes more sense. I am not entirely convinced that the choice of language itself will make the difference vs the new architecture which is quite different

Re: [Discussion] Use TransactionID as ActivationID

Related discussion in this issue https://github.com/apache/ incubator-openwhisk/issues/3083 with a connection to open-tracing. -r

Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache

> I have been working my bones out during the past months to make sure openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go, openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube under 0.9.x version matching, and they work together. As long as the runtimes work ok with them,

Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache

> --dave > >> >> >> >> Best wishes. >> Vincent Hou (侯胜博) >> >> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM > Cloud >> >> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, >> Phone: +

Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache

Why do they all need to start from the same version? On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou wrote: > Hi OpenWhiskers, > > We are on our way to release OpenWhisk runtimes under Apache for the first > time. As you may notice or not, each individual runtime repository has > already used >

Re: Kafka and Proposal on a future architecture of OpenWhisk

> A second idea that comes to my mind would be to implement a shared counter (it can easily be eventually consistent, consistency is I think not a concern here). This is simply a drive-by comment, as I have not directly weighed in on the rest of the discussion. But this comment about a shared

Re: Reminder: Tech Interchange meeting tomorrow, Wed Aug 15th

Looks like a nice agenda. Thanks Ben for hosting this one. I can’t make it unfortunately but will catch the replay. Dragos’ AI actions might be another although maybe the runway too short. -r > On Aug 14, 2018, at 9:09 AM, Ben Browning wrote: > > Greetings! > > Our next tech interchange

Re: Pluggable API Gateways

> One possibility would be to create a layer that sits in between Whisk > "proper" and a given gateway implementation that knows how to take a common > set of directives and translate them into whatever DSL the target gateway > understands. Isn’t this what the route management package does, with

Re: Pluggable API Gateways

laying with >> golang. Regardless, I do think it should come as a follow-on effort, with >> the current model being the first plugin we build -- which will >> coincidentally work against at least the current gateway and the traefik >> one I'm trying to implement. >>

Re: Pluggable API Gateways

Hi Henry Fundamentally, I agree with you and think what you're proposing is a good way forward. Specifically, based on my own experience helping others integrate their own API gateways, I've found a few issues which I've tried to slowly fix. 1. The openwhisk deployment and route management

Re: Further test suite improvements

Thanks Martin - this is great IMO. I posted a couple of comments in support of this and some tips for a faster review. -r > On Aug 6, 2018, at 2:14 PM, Martin Gencur wrote: > > Hello all, > in an effort to improve the OpenWhisk test suite I'd like to propose some > changes which I described

Re: System env vars in user containers

> So what are the invoker changes that will leverage these runtime changes? I’m > not sure that context was part of the thread yet, sorry if it was. It wasn’t but without invoker changes this in itself isn’t very useful. You are right. -r

Re: [DISCUSSION]: Release plan of OpenWhisk 0.9.0 for all modules

Hi Vincent All the runtimes have change logs docker skeleton v1.3.2 https://github.com/apache/incubator-openwhisk-runtime-docker/blob/master/core/CHANGELOG.md#132 python2 v1.0.2 https://github.com/apache/incubator-openwhisk-runtime-python/blob/master/core/python2Action/CHANGELOG.md#102 python3

Re: System env vars in user containers

> Ideally we need to remove most of our env vars from /run to /init, I agree. > But wouldn't it be a breaking change then? > I don't think so - the first time a container is started, the values are provided on init. On run, the values that change would be provided (activation id, deadline). >

Re: System env vars in user containers

> Should we reduce dependency on env variable to communicate such state? Oy. That’s right the activation id and deadline will conflict. What are you thinking as an alternarive? -r

Re: System env vars in user containers

+1 for backward compatibility. I would also provide the env vars at init time. (Currently they’re available at run time). The api host is provided as a container env var is partly historical and partly because it’s the same for all containers so it was remained factored out when we added

Re: OpenWhisk Website Redesigned

> If that's correct, note that in general in Apache projects those > people are called "Users", because they are users of the software that > we produce, and the "Developers" are the people who write the > OpenWhisk software that the ASF releases. > > With my incubation mentor hat on I would

Re: [DISCUSSION]: Release plan of OpenWhisk 0.9.0 for all modules

Hi Vincent, what do you mean by a group - is it a single tar ball that includes a directory for each git repository? without knowing specifically what you mean by a group, the following may not make sense but - catalog and apigatway should be orthogonal - can you explain the logic behind

Re: Tech Interchange meeting Wednesday

Hi Justin. Thanks for thinking of me for the update. I can speak briefly about the cve and will plan to attend. -r

Re: runtime images tagged "master" vs "latest"

> So far runtimes updates are very slow traffic and have not need this small > window so far, so maybe we can leave it as "latest" is bleeding edge. That’s my preference also. One less tag and avoids confusion. So “latest” and explicit tags corresponding with change logs. -r

Re: MiniWhisk: what you think?

> My approach was to implement the OpenWhisk platform API > using a stub server that would execute the actions using Docker in the host > system. You really don’t need this though - look at the invoker.py script. That is enough IMO, either extending that or copying that into a new executable

Re: MiniWhisk: what you think?

https://github.com/ibm-functions/shell -r > On Jul 25, 2018, at 4:10 PM, Michele Sciabarra > wrote: > > Sorry for the stupid question but which shell? bx ? wsk ? > > Because the build part could be implemented using existing solutions (there > are many) > > -- > Michele Sciabarra >

Re: New Downloads page for our project website

I created a PR to change the download link for the source tarball: https://github.com/apache/incubator-openwhisk-website/pull/258/files Do we need to use the mirroring system for the signature files also? -r > On Jul 23,

Re: Where to contribute examples for Golang?

> Currently, the READMEs are all quite different in assumption of role/reason a developer might go there and most are not typically great for the most important role "Action developer"; we need to consider this role when authoring and will do so in any template proposal. Hi Matt indeed as I

Re: Where to contribute examples for Golang?

ten in Go and integrated in > the travis build (it was hard enough as the timing in Travis are different > than on a mac). > > -- > Michele Sciabarra > openwh...@sciabarra.com > > - Original message - > From: Rodric Rabbah > To: dev@openwhisk.apache.org >

Re: Where to contribute examples for Golang?

> I am afraid that trying to provide those examples without agreeing "the receiver" would end getting the same destiny of my other PR for tests... So please give directions. I suggest the content and examples are provided in its own runtime repos in a canonical place that we document here [1]

Re: Where to contribute examples for Golang?

> I contributed ScalaTest tests for my runtime to the main repository, as it was requested, and my PR was closed because now they should be moved ... in the runtime. Do you have a link for the PR? This query doesn't return anything

Re: Where to contribute examples for Golang?

> One problem (and personal frustration) of the openwhisk project is that is so vast in term of repositories that unless someone knows and wait for the PR, your contribute go unnoticed. I wholly share this sentiment - there are too many repositories and interdependence. I also do think a release

Re: Where to contribute examples for Golang?

Some thoughts of the top, we should have: - accessing function parameters, - returning an http response form a webaction, - decoding a base64 payload (webaction), - working with context parameters in the environment On Sat, Jul 21, 2018 at 8:25 AM, Michele Sciabarra wrote: > In the latest

[CVE] CVE-2018-11757 Docker Skeleton Runtime for Apache OpenWhisk

Who is Affected: Apache OpenWhisk users with an explicitly created Docker action, and the Docker image used for the action inherits from the affected Docker tag: - openwhisk/dockerskeleton < 1.3.1 The Docker Skeleton Runtime does not currently have any Apache releases. Description: A Docker

[CVE] CVE-2018-11756 PHP Runtime for Apache OpenWhisk

Who is Affected: Apache OpenWhisk users with an explicitly created Docker action, and the Docker image used for the action inherits from the affected Docker tags: - openwhisk/action-php-v7.2 < 1.0.1 - openwhisk/action-php-v7.1 < 1.0.2 The PHP Runtime does not currently have any Apache releases.

Re: Proposal on a future architecture of OpenWhisk

Hi Mark This is precisely captured by the serverless contract article I published recently: https://medium.com/openwhisk/the-serverless-contract-44329fab10fb Queue, reject, or add capacity as three potential resolutions under load. -r > On Jul 18, 2018, at 8:16 AM, Martin Gencur wrote: >

Re: Proposal on a future architecture of OpenWhisk

> On Jul 17, 2018, at 4:49 AM, Markus Thoemmes > wrote: > > The design proposed does not intent to change the way we provide > oberservibility via persisting activation records. It is worth considering how we can provide observability for activations in flight. As it stands today, as a

Re: Proposal on a future architecture of OpenWhisk

Regarding at least or at most once: Functions should be stateless and the burden is on the action for external side effects anyway... so it’s plausible with these in mind that we contemplate shifting modes (a la lambda). There are cases though that we should retry that are safer: in flight

Re: Add support for microkernels instead of containers

Hi James There’s an abstract interface to the execution unit in the invoker: Start/Pause/Resume/Stop/Logs. You can select the implementation through a configuration deployment (SPI). There was some work on using the interface I alluded to for unikernels. I’d imagine the interface it can be

Re: System overflow based on invoker status

Hi Markus Per our discussion on slack, I’m documenting below the concerns we discussed. (And thanks for fixing my math bug.) The approach of being more introspective to detect overload is a good improvement over the ad hoc value set today. Thanks for bringing this up. This is a general

Re: Proposing Lean OpenWhisk

Glad to see this work reaching maturity. As Markus noted I think there could be more convergence down the line too. Looking forward to the PR. -r > On Jul 16, 2018, at 4:17 AM, David Breitgand wrote: > > Hi, > > Pavel and I are working on lean OpenWhisk. The idea is to allow an efficient

Re: Concurrency in invoker http client

> On Jul 13, 2018, at 8:21 PM, Markus Thoemmes > wrote: > > As a more general, existential question: Do we even need the truncation path? > Could we just deny the response straight away if the user's action returns a > bigger value than allowed? Thanks for asking the question. We could

Re: [GitHub] bwmcadams opened a new pull request #1: Migration of Red Hat's existing work to the new ASF Incubator Repo

Hi Matt I think we need an INFRA ticket to disable repo notifications to dev list. -r On Thu, Jul 12, 2018 at 2:05 PM, GitBox wrote: > bwmcadams opened a new pull request #1: Migration of Red Hat's existing > work to the new ASF Incubator Repo > URL:

runtime images tagged "master" vs "latest"

I noticed while checking the runtime repos that the Travis builds off master push docker images for the runtimes with the tag "master" which is not the same as "latest". The openwhisk repo's runtime manifest uses "latest" as the default tag so a vanilla deployment will pull stale images. I'll try

Re: should we enable signed commits on our github repos?

Hi Matt, I think the concern is for the runtime repso, and the cli related repos for example: https://github.com/apache/incubator-openwhisk-runtime-nodejs/releases all the runtime repos and the cli have "releases" which are not the same - we used this more as stable builds for dependence

Re: New Git repo. incubator-openwhisk-deploy-openshift created

Great to hear. Thanks Matt for setting up the repo and Brendan, Ben and others for the contributions. -r On Wed, Jul 11, 2018 at 11:17 AM, Matt Rutkowski wrote: > OpenWhiskers, > > In order to facilitate our understanding what Red Hat has done with the > OpenWhisk codebase in order to get it

Re: should we enable signed commits on our github repos?

project for the inexperienced to > contribute to. > > Regards, > > Rob > > > On 10 Jul 2018, at 16:41, Rodric Rabbah wrote: > > > > Who knows why we haven't enabled signed commits on the apache repos - > > should we require all commit

should we enable signed commits on our github repos?

Who knows why we haven't enabled signed commits on the apache repos - should we require all commits to be signed? -r Ref: https://help.github.com/articles/signing-commits-using-gpg/

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating rc2: main OpenWhisk module

I vote +1 for Release as Apache OpenWhisk 0.9.0-incubating Checklist for reference: [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

share additional deployment related limits through API host

currently if you query the API host (GET /openwhisk) you get a response which includes the deployment manifest and action invocation limits. I've added in this PR [1] additional limits to include the min/max action duration, memory size and log size so the response looks like: "limits": {

Re: Proposing Ballerina Runtime for OpenWhisk

Hi Malith I’ve made a number of updates to the runtime test framework as part of documenting runtime integration (merged as [1]). These are in a PR that I hope gets merged in the next day or two. I can send a PR [2] to your repo to update the tests for the new interface (I think you’ll find it

Re: Let's maintain and test our Swagger spec

Ben, you might want to take note of this PR https://github.com/apache/ incubator-openwhisk/pull/3840 which removes a number of tests suites (redundant with unit tests). Also I've found that the WskRestOperations implementation in some places fixes behaviors to match the CLI instead of strictly

Re: Let's maintain and test our Swagger spec

That's fantastic! Thanks Ben for taking this on... so long overdue. On Thu, Jul 5, 2018 at 9:20 PM, Ben Browning wrote: > After several failed attempts, I have an approach that I believe will > work well enough for our needs. I pushed some in-progress code and > swagger spec fixes to a branch

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating rc2: main OpenWhisk module

This was removed: > On Jul 3, 2018, at 2:55 PM, Vincent S Hou wrote: > > > The MD5 checksum for each artifact can be found via: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/openwhisk-0.9.0-incubating-sources.tar.gz.md5 > >

Re: Proposing Ballerina Runtime for OpenWhisk

Thank you Malith for introducing Ballerina to OpenWhisk. We have received in the past contributions to add PHP (thanks @akrabat ), Go (thanks @sciabarracom ) Ruby (#3725

Re: Recover image pulls by trying to run the container anyways.

+1 to make the change - as noted this is for the better in terms of running docker actions in prod. -r > On Jul 3, 2018, at 3:07 AM, Markus Thoemmes > wrote: > > Hi, > > Thanks for the clarification Rodric, wasn't aware of that. I think it still > holds though that "latest" should mean

Re: [DISCUSS] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module

ts, but take into account you will need to be on top of the findings > which would be similar as the found in the dev list. > > -- Carlos > >> On Fri, Jun 29, 2018 at 2:19 PM Rodric Rabbah wrote: >> >> Thanks. >> >> -r >> >>> On Jun 29,

Re: [DISCUSS] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module

; > Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud > > Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, > Phone: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States > > -Rodric Rabbah

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module

s...@us.ibm.com, > Phone: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States > > -Rodric Rabbah wrote: - > To: dev@openwhisk.apache.org > From: Rodric Rabbah > Date: 06/29/2018 08:04AM > Subject: Re: [VOTE] R

[DISCUSS] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module

I am breaking this out into a DISCUSS thread so not to pollute the vote. In completing this checking list: [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

Feedback sought for reorg of documentation

Based on a discussion with Carlos and Rob on a PR related to the php runtime I reorganized and split our docs introducing actions (create, invoke) and the language specific parts. I’m working up toward adding a doc that describes how to add a new runtime (and refactoring of the tests to also

Re: Recover image pulls by trying to run the container anyways.

In general I think this is a good change - but minor nit that "latest" in docker doesn't mean pull the latest tag. -r On Wed, Jun 27, 2018 at 7:35 AM, Markus Thoemmes wrote: > Dear OpenWhiskers, > > when using Blackbox actions, whenever OpenWhisk creates a new container > "docker pull" is

Re: ArtifactStore shutdown handling and shared resources

+1 to refcount, i think it's better to shut down the pool then possibly leave open connections that may cause trouble when you replace a controller in production. the implementation seems straightforward here. -r On Tue, Jun 26, 2018 at 1:40 AM, Chetan Mehrotra wrote: > > it hasn’t been clear

Re: Concurrency in invoker http client

the retires are only on failure to establish a connection - no other retries should be happening iirc. -r On Mon, Jun 25, 2018 at 1:29 PM Tyson Norris wrote: > Thanks Markus - one other question: > > Assuming retry is the current missing piece to using PoolingRestClient (or > akka http

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating

> On Jun 22, 2018, at 8:18 AM, Vincent S Hou wrote: > > I mean if only release this go client code, there is nothing we can run it > against. And that is entirely fine per all the ASF docs I’ve read. Is there a requirement that the code must be functional in some extended capacity? The ASF

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating

> As long as the ASF incubator people are happy with a release that doesn’t > have the org.apache.openwhisk.* package name, it all seems fine. Can we find out by asking first before getting slammed later? -r

<    1   2   3   4   5   6   7   >