Re: [VOTE] Release Apache OpenWhisk Client Js (v3.21.4, rc1)
+1 to release Apache OpenWhisk Client Js (v3.21.4, rc1) Checked with rcverify. On Fri, 30 Apr 2021 at 23:14, Rodric Rabbah wrote: > Hi, > > This is a call to vote on releasing version 3.21.4 release candidate rc1 > of the following project module with artifacts built from the Git > repositories and commit IDs listed below. > > * OpenWhisk Client Js: c697f0be4a254a4d0ff8f98c4e746f479072fb7a > > https://github.com/apache/openwhisk-client-js/commit/c697f0be4a254a4d0ff8f98c4e746f479072fb7a > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-js-3.21.4-sources.tar.gz > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-js-3.21.4-sources.tar.gz.asc > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-js-3.21.4-sources.tar.gz.sha512 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=2d4d5d9 > > Usage: > curl -s " > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=2d4d5d9; > -o rcverify.sh > chmod +x rcverify.sh > ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.21.4 rc1 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] Source code artifacts have correct names matching the current > release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers as specified by OpenWhisk project > policy [1]. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > > > [1] > https://github.com/apache/openwhisk-release/blob/master/docs/license_compliance.md -- Regards, James Thomas
Re: [DISCUSS] update release of npm client
+1 On Fri, 9 Apr 2021 at 19:27, Matt Rutkowski wrote: > +1 All for keeping our clients updated and released regularly. > > > -- Regards, James Thomas
Re: Allow decision about action result inclusion in logs on a per call basis
This is a sensible change and I agree with what Rodric has suggested: can we make this a per-action annotation? On Tue, 3 Sep 2019 at 13:28, Rodric Rabbah wrote: > > > Action results may contain sensible data that should not be logged. > > I interpret this to mean: not stored in the activation record. > > If this is what you mean, why not make this a feature controlled per action > using an annotation and let the user decide: ok to save the result, not ok > to save the result, only save the result on error. > > -r > > On Tue, Sep 3, 2019 at 8:17 AM Ruediger Maass > wrote: > > > Action results may contain sensible data that should not be logged. There > > is a system configuration flag (writeResultToFile) that can be used to > > switch on or off the result inclusion in logs. But this is a global switch > > that holds for all activations. In our case we want to able to decide per > > activation whether or not the result should be included in the log or not. > > In our special case we want results to be included in case of errors (in > > other words, our predicate function for the decision is: 'Does the result > > contain an error field?'). But also other decision logic may be > > applicable. > > > > This PR https://github.com/apache/openwhisk/pull/4604 is a small change > > that extends ActivationFileStorage. > > > > Please help and comment on the PR. > > > > Thank you, Ruediger > > > > -- Regards, James Thomas
[ANNOUNCE] Apache OpenWhisk Client JS 3.20.0 Released
The Apache OpenWhisk project is happy to announce the release of Apache OpenWhisk Client JS 3.20.0. Apache OpenWhisk Client JS is a JavaScript Client Library for the Apache OpenWhisk Platform. New features in the 3.20.0 version include: - Removed all references to Incubator now Apache OpenWhisk has passed incubation. - Add proxy agent to be included by runtime, rather than building in (#175) - Re-worked CI/CD setup (#180) https://github.com/apache/openwhisk-client-js/releases/tag/3.20.0 Source archives and verification files are available at https://dist.apache.org/repos/dist/release/openwhisk/apache-openwhisk-3.20.0/ -- Regards, James Thomas
[RESULT][VOTE] Release Apache Apache OpenWhisk Client Js (v3.20.0, rc2)
The voting is now closed. The vote has PASSED with 4 +1 binding votes from Dominic Kim, Matt Rutkowski, Dave Grove and Rob Allen. There were no +0 or -1 votes. I will now publish the artifact to the release directory. On Mon, 19 Aug 2019 at 12:32, James Thomas wrote: > > Hi, > > This is a call to vote on releasing version 3.20.0 release candidate > rc2 of the following project module with artifacts built from the Git > repositories and commit IDs listed below. > > * Apache OpenWhisk Client Js: 88ce0e2 > https://github.com/apache/openwhisk-client-js/commits/88ce0e2 > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.asc > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.sha512 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh' > > Usage: > curl -s > "https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;; > -o rcverify.sh > chmod +x rcverify.sh > ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.20.0 rc2 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers as specified by OpenWhisk project > policy [1]. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > > > [1] > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md > > -- > Regards, > James Thomas -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.11.0, rc1)
+1 Checked with: rcverify.sh (script SHA1: BD88 60D6 13CC 8470 4395 5E9C B986 D8DD 71A2 E9F1) On Tue, 27 Aug 2019 at 10:40, Rob Allen wrote: > > +1 Approve. > > Checked with rcverify.sh (script SHA1: BD88 60D6 13CC 8470 4395 5E9C B986 > D8DD 71A2 E9F1) > > Regards > > Rob > > > On 26 Aug 2019, at 23:23, David P Grove wrote: > > > > > > > > Hi, > > > > This is a call to vote on releasing version 0.11.0 release candidate rc1 of > > the following project module with artifacts built from the Git repositories > > and commit IDs listed below. > > > > * OpenWhisk API Gateway: b80ce4db0828f9cc4250688023214103199235c2 > > > > https://github.com/apache/openwhisk-apigateway/commits/b80ce4db0828f9cc4250688023214103199235c2 > > > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-0.11.0-rc1/openwhisk-apigateway-0.11.0-sources.tar.gz > > > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-0.11.0-rc1/openwhisk-apigateway-0.11.0-sources.tar.gz.asc > > > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-0.11.0-rc1/openwhisk-apigateway-0.11.0-sources.tar.gz.sha512 > > > > This release is comprised of source code distribution only. > > > > You can use this UNIX script to download the release and verify the > > checklist below: > > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=878716a > > > > Usage: > > curl -s " > > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=878716a > > " -o rcverify.sh > > chmod +x rcverify.sh > > rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' 0.11.0 rc1 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > Release verification checklist for reference: > > [ ] Download links are valid. > > [ ] Checksums and PGP signatures are valid. > > [ ] Source code artifacts have correct names matching the current > > release. > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > > [ ] All files have license headers as specified by OpenWhisk project > > policy [1]. > > [ ] No compiled archives bundled in source archive. > > > > This majority vote is open for at least 72 hours. > > > > > > [1] > > https://github.com/apache/openwhisk-release/blob/master/docs/license_compliance.md > -- Regards, James Thomas
[VOTE] Release Apache Apache OpenWhisk Client Js (v3.20.0, rc2)
Hi, This is a call to vote on releasing version 3.20.0 release candidate rc2 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * Apache OpenWhisk Client Js: 88ce0e2 https://github.com/apache/openwhisk-client-js/commits/88ce0e2 https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.sha512 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below: https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh' Usage: curl -s "https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;; -o rcverify.sh chmod +x rcverify.sh ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.20.0 rc2 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers as specified by OpenWhisk project policy [1]. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. [1] https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md -- Regards, James Thomas
Re: Try out the api gateway support in standalone server (#4571)
rl=130 rt=0.008 hr="-" > > > ua="curl/7.54.0" xfwdf="-" upadd="192.168.65.2:3233" upstat=404 uprt=0.007 > > > tenantId="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" > > > tenantNamespace="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" tenantInstance="" > > > requestHeaders="" requestBody="" responseHeaders="" responseBody="" > > > apiId="8a68d0a9-a024-4411-9233-7ba1d9099b1a" apiKey="-" > > > analyticsUri="/hello/world" reqid="zvL6RbV0qtiZ0BakfDGudINV8Gzv1Ocl" > > > > > > ==> /var/log/api-gateway/gateway_error.log <== > > > 2019/07/29 14:50:45 [info] 35#0: *21 client 172.17.0.1 closed keepalive > > > connection > > > 2019/07/29 14:50:48 Executing sync cmd: echo '' > > > sync stdout | '' > > > 2019/07/29 14:50:48 done > > > > > > > > > -r > > > > > > > > > > > > On Mon, Jul 29, 2019 at 7:53 AM Chetan Mehrotra > > > > > > wrote: > > > > > > > Hi Team, > > > > > > > > As discussed in last Tech Interchange call support is now being added > > > > to launch the Api Gateway with Standalone Server [1]. With this it > > > > should be possible to direct new OpenWhisk users to use the Standalone > > > > server to try out various features provided by OpenWhisk > > > > > > > > So far tests look fine and would now like to seek some feedback from > > > > community on this feature. For this it would be helpful if you can try > > > > out a beta build and see if it works as expected > > > > > > > > # Fetch custom docker build of apigateway which has > > > > apache/incubator-openwhisk-apigateway#347 fixed > > > > $ docker pull chetanmeh/apigateway > > > > > > > > # Download the openwhisk-standalone jar > > > > $ wget > > > > > > > https://github.com/chetanmeh/incubator-openwhisk/releases/download/0.11/openwhisk-standalone.jar > > > > $ java -Dwhisk.standalone.api-gateway.image=chetanmeh/apigateway -jar > > > > openwhisk-standalone.jar --api-gw > > > > > > > > Post this you can use the steps as mentioned in [2] to check out the > > > > gateway support. > > > > > > > > Please share any feedback on #4571 or this mail thread > > > > > > > > Chetan Mehrotra > > > > [1] https://github.com/apache/incubator-openwhisk/pull/4571 > > > > [2] > > > > > > > https://github.com/apache/incubator-openwhisk/blob/master/docs/apigateway.md > > > > > > > -- Regards, James Thomas
Re: housecleaning of openwhisk git repos
Looking over the list, here's a few thoughts from me on the "TO DECIDE" list... - incubator-openwhisk-external-resources: This (popular) list of OW content can probably be archived. I've stop maintaining it. - incubator-openwhisk-workshop: I'm not sure this even works anymore[1] - happy to archive. - incubator-openwhisk-tutorial: Don't think this works? Should archive. - incubator-openwhisk-client-swift: Unmaintained (wouldn't assume it still works...) - Archive. - incubator-openwhisk-slackinvite: Still being used but not updated - archive? [1] - https://github.com/apache/incubator-openwhisk-workshop/blob/master/exercises/setting_up_cli/exercise.js#L19 On Thu, 1 Aug 2019 at 21:21, David P Grove wrote: > > Appended is Chetan's list of repos broken into suggested KEEP (28 repos), > NEED DECISION (10 repos) , and ARCHIVE (14 repos) sections. > > I plan to open a ticket for infra to rename (remove incubator-) for the 28 > repos on the KEEP list tomorrow. Will hold off on acting on the other 24 > for now. > > --dave > > KEEP > 1 | incubator-openwhisk| 2019-07-24 > 2 | incubator-openwhisk-website| 2019-07-23 > 3 | incubator-openwhisk-cli| 2019-07-22 > 4 | incubator-openwhisk-runtime-swift | 2019-07-22 > 5 | incubator-openwhisk-runtime-go | 2019-07-20 > 6 | incubator-openwhisk-runtime-nodejs | 2019-07-18 > 7 | incubator-openwhisk-runtime-rust | 2019-07-18 > 8 | incubator-openwhisk-deploy-kube| 2019-07-18 > 9 | incubator-openwhisk-client-js | 2019-07-16 > 10| incubator-openwhisk-runtime-python | 2019-07-12 > 11| incubator-openwhisk-devtools | 2019-07-11 > 12| incubator-openwhisk-utilities | 2019-07-10 > 13| incubator-openwhisk-release| 2019-07-09 > 14| incubator-openwhisk-catalog| 2019-07-08 > 15| incubator-openwhisk-wskdeploy | 2019-07-05 > 16| incubator-openwhisk-composer | 2019-07-04 > 17| incubator-openwhisk-runtime-php| 2019-07-03 > 18| incubator-openwhisk-runtime-java | 2019-07-03 > 19| incubator-openwhisk-apigateway | 2019-07-01 > 20| incubator-openwhisk-package-alarms | 2019-06-29 > 21| incubator-openwhisk-package-cloudant | 2019-06-29 > 22| incubator-openwhisk-package-kafka | 2019-06-29 > 23| incubator-openwhisk-runtime-ballerina | 2019-06-29 > 24| incubator-openwhisk-runtime-dotnet | 2019-06-29 > 25| incubator-openwhisk-runtime-ruby | 2019-06-29 > 26| incubator-openwhisk-runtime-docker | 2019-06-29 > 27| incubator-openwhisk-client-go | 2019-06-29 > 28| incubator-openwhisk-pluggable-provider | 2019-06-24 > > > NEED DECISION: > 29| incubator-openwhisk-test | 2019-05-31 > 31| incubator-openwhisk-composer-python| 2019-03-20 > 32| incubator-openwhisk-external-resources | 2019-02-10 > 33| incubator-openwhisk-workshop | 2019-01-24 > 34| incubator-openwhisk-package-pushnotifications | 2019-01-08 > 35| incubator-openwhisk-package-deploy | 2018-11-07 > 36| incubator-openwhisk-tutorial | 2018-07-30 > 37| incubator-openwhisk-client-swift | 2018-05-09 > 38| incubator-openwhisk-deploy-mesos | 2018-04-16 > 39| incubator-openwhisk-slackinvite| 2017-12-29 > > > ARCHIVE: > 30| incubator-openwhisk-deploy-openshift | 2019-05-20 > 40| incubator-openwhisk-vscode | 2017-11-03 > 41| incubator-openwhisk-package-rss| 2017-09-27 > 42| incubator-openwhisk-xcode | 2017-08-21 > 43| incubator-openwhisk-package-template | 2017-08-17 > 44| incubator-openwhisk-debugger | 2017-07-20 > 45| incubator-openwhisk-sample-matos | 2017-07-14 > 46| incubator-openwhisk-playground | 2017-07-12 > 47| incubator-openwhisk-podspecs | 2017-07-12 > 48| incubator-openwhisk-client-python | 2017-07-10 > 49| incubator-openwhisk-package-jira | 2017-07-10 > 50| incubator-openwhisk-selfserve-test | 2017-06-26 > 51| incubator-openwhisk-GitHubSlackBot | 2017-03-16 > 52| incubator-openwhisk-sample-slackbot| 2017-01-25 -- Regards, James Thomas
Re: [VOTE] Release Apache Apache OpenWhisk Client JS (v3.20.0, rc1)
Good catch Dave! Will work on RC2 :) On Fri, 2 Aug 2019 at 21:47, Dave Grove wrote: > > Sorry James. > > I vote -1 because the release contains the incubator DISCLAIMER. I > submitted a PR to remove [1] > > Otherwise it looks good. I ran rcverify and also ran Apache Rat 0.13 and > found no other problems. > > --dave > > [1] https://github.com/apache/incubator-openwhisk-client-js/pull/189 > > On 2019/08/01 15:44:50, James Thomas wrote: > > Hi, > > > > This is a call to vote on releasing version 3.20.0 release candidate > > rc1 of the following project module with artifacts built from the Git > > repositories and commit IDs listed below. > > > > * Apache OpenWhisk Client JS: 9b877bb > > https://github.com/apache/openwhisk-client-js/commits/9b877bb > > > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc1/openwhisk-client-js-3.20.0-sources.tar.gz > > > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc1/openwhisk-client-js-3.20.0-sources.tar.gz.asc > > > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc1/openwhisk-client-js-3.20.0-sources.tar.gz.sha512 > > > > This release is comprised of source code distribution only. > > > > You can use this UNIX script to download the release and verify the > > checklist below: > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh > > > > Usage: > > curl -s > > "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh; > > -o rcverify.sh > > chmod +x rcverify.sh > > ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.20.0 rc1 > > > > Please vote to approve this release: > > > > > > -- Regards, James Thomas
Feedback on Release Process Instructions
Hello Whiskers. I've just run through the first release for a project component since the graduation (and automatic release publishing using Travis was forbidden...). Thanks for Dave Grove for doing a first pass at updating the instructions for the new manual post-incubation release process. I came across a few doc issues I wanted to raise for feedback... https://github.com/apache/incubator-openwhisk-release/blob/master/docs/prepare_release.md - Step 4: CHANGELOG - Is a changelog in a project mandatory or just a nice to have? - Step 5: JIRA issues. Is a JIRA issue necessary? I can't find reference to this in the ASF docs. I did previously open one before a "VOTE" and was told it wasn't correct (https://issues.apache.org/jira/browse/INCUBATOR-232?filter=-2). I've also opened an issue to create a "single release" script to cut out the need to run dozens of individual steps manually. https://github.com/apache/incubator-openwhisk-release/issues/293 -- Regards, James Thomas
[VOTE] Release Apache Apache OpenWhisk Client JS (v3.20.0, rc1)
Hi, This is a call to vote on releasing version 3.20.0 release candidate rc1 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * Apache OpenWhisk Client JS: 9b877bb https://github.com/apache/openwhisk-client-js/commits/9b877bb https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc1/openwhisk-client-js-3.20.0-sources.tar.gz https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc1/openwhisk-client-js-3.20.0-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc1/openwhisk-client-js-3.20.0-sources.tar.gz.sha512 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below: https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh Usage: curl -s "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh; -o rcverify.sh chmod +x rcverify.sh ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.20.0 rc1 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers as specified by OpenWhisk project policy [1]. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. -- Regards, James Thomas
Re: [DISCUSS] Apache OpenWhisk Client JS Release v3.20.0
Definitely - looking back at the thread[1], these were the issues raised: - A large number of .js files in the test directory and many other places don’t have the correct ASF header. - the LICENSE incorrectly includes "Copyright 2015-2016 IBM Corporation” in the appendix - Info in package.json needs updating as it refers to the pre ASF project These have all been resolved since that release (with a final license issue caught by Dave's updated scancode): https://github.com/apache/incubator-openwhisk-client-js/pull/187 [1] - https://www.mail-archive.com/general@incubator.apache.org/msg67643.html On Mon, 22 Jul 2019 at 17:16, Rodric Rabbah wrote: > > This will be the first release post graduation. I’d like to make sure we’ve > gone through and closed issues raised in previous incubator votes. > > -r > > > On Jul 22, 2019, at 12:10 PM, James Thomas wrote: > > > > I've finished up the remaining backlog items planned for the next > > release (v3.20.0) of the Apache OpenWhisk Client JS SDK. Does anything > > have anything else to add in before I start cutting the first RC? > > > > https://github.com/apache/incubator-openwhisk-client-js/milestone/1?closed=1 > > > > This new release fixes a number of issues regarding correct license > > files raised in the last release[1], resolves the accidental increase > > in package size (and adds a CI check to prevent this happening > > again)[2], updates all project deps to recent versions[3] and fixes > > some minor issues. > > > > > > [1] - https://github.com/apache/incubator-openwhisk-client-js/issues/162 > > [2 - https://github.com/apache/incubator-openwhisk-client-js/issues/158 > > & https://github.com/apache/incubator-openwhisk-client-js/issues/159 > > [3] - https://github.com/apache/incubator-openwhisk-client-js/issues/177 > > -- > > Regards, > > James Thomas -- Regards, James Thomas
[DISCUSS] Apache OpenWhisk Client JS Release v3.20.0
I've finished up the remaining backlog items planned for the next release (v3.20.0) of the Apache OpenWhisk Client JS SDK. Does anything have anything else to add in before I start cutting the first RC? https://github.com/apache/incubator-openwhisk-client-js/milestone/1?closed=1 This new release fixes a number of issues regarding correct license files raised in the last release[1], resolves the accidental increase in package size (and adds a CI check to prevent this happening again)[2], updates all project deps to recent versions[3] and fixes some minor issues. [1] - https://github.com/apache/incubator-openwhisk-client-js/issues/162 [2 - https://github.com/apache/incubator-openwhisk-client-js/issues/158 & https://github.com/apache/incubator-openwhisk-client-js/issues/159 [3] - https://github.com/apache/incubator-openwhisk-client-js/issues/177 -- Regards, James Thomas
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 Project Chair (Duo Zhang, VP) > > Establish the Apache OpenWhisk Project (Dave Grove, VP) > > Change the Apache Attic Project Chair (Mads Toftum, VP) > > > \o/ > > Rob -- Regards, James Thomas
Re: Re: Changing JavaScript SDK NPM Module Name: openwhisk => apache-openwhisk?
I've discovered the Cordova project publishes all their project repos without the `apache-` prefix. https://www.npmjs.com/search?q=cordova Same goes for thrift (https://www.npmjs.com/package/thrift). I've guess there's precedence that maybe this isn't an issue? On Mon, 15 Jul 2019 at 18:17, Matt Sicker wrote: > > Most or all of the Apache projects that are distributed on Homebrew > <https://brew.sh/> are named apache-foo. > > ...except for `wsk` and `wskdeploy` which are curiously lacking > `apache-` prefixes as well. ;) > > On Mon, 15 Jul 2019 at 12:08, Matt Rutkowski wrote: > > > > I too like the dash approach unless Apache likes having a domain name > > style which implies (family) membership hierarchy. > > > > > > > > From: Matt Sicker > > To: dev@openwhisk.apache.org > > Date: 07/15/2019 12:05 PM > > Subject:[EXTERNAL] Re: Changing JavaScript SDK NPM Module Name: > > openwhisk => apache-openwhisk? > > > > > > > > The name with the dash looks nicer, agreed. In migrating from an old > > package name to a new one where you already have existing users, I > > haven't seen a solution to that myself quite yet, though I know that > > Groovy has a similar problem where their packages are still published > > under the `org.codehaus.groovy` group id instead of > > `org.apache.groovy`. While Maven and NPM are quite different, the > > method of migrating a package name is similarly not well-defined in > > both systems. > > > > Does anyone have more info about how NPM runs their repository? Maybe > > they can add in some redirects of some sort. > > > > On Mon, 15 Jul 2019 at 11:11, James Thomas wrote: > > > > > > Reviewing the ASF guidelines on NPM packages to check our JS SDK > > satifises > > > all the rules[1] - we're supposed to be publishing the NPM package as > > > "apacheopenwhisk" and not "openwhisk". This NPM library was published at > > ( > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.npmjs.com_package_openwhisk=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=C-3wIDNjUO6k1tpWW7WQA9d4c-lbe7KshNS1jAR6jxM= > > ) before the project was donated to > > > Apache. > > > > > > Moving from the library to publish at `apache-openwhisk` rather than > > > `openwhisk`[2] is not technically challenging (and the new package name > > is > > > available) but will cause numerous issues > > > > > > I'm asking for comments on what to do about this. Would like to engage > > the > > > ASF mentors for advice as well. What does the community think about > > this? > > > > > > The library has significant usage (NPM tells me the library is averaging > > 6k > > > downloads a week) using the existing package name. GitHub lists 38K > > > references to the module. > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_search-3Fq-3Drequire-2528-2522openwhisk-2522-2529-26type-3DCode=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=nIOIJxXhbd1TkXzWJVHx9-NAMQV4JuBsXbm1pEkX8u0= > > > > > > > > All those external dependent projects, blog posts, documentation and > > > tutorials, etc, that reference the library (and are outside of our > > control) > > > will be reliant on the old package name. These will still work (as the > > old > > > library version will still be available from NPM) but never receive new > > > versions on installing the dependency. This may eventually mean the old > > > library doesn't work with future platform changes and/or lead to > > security > > > issues with outdated dependencies. > > > > > > I'm not sure if there's any leeway in the allowing the short-name for > > the > > > NPM library (given we follow all the other requirements)? This will be a > > > significant amount of work just changing all the references in project > > we > > > control. > > > > > > If we do change the name - I'd assume `apache-openwhisk` is fine. Using > > > `apacheopenwhisk` is slightly horrid > > > > > > [1] - > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D109454613=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=ZshMeW40IVmdVpBrfK3b_ERcnaA4Bh7h3iqXvO_NDCc= > > > > > [2] - following NPM JS module conventions - apache-openwhisk is much > > > preferable than a single word (apacheopenwhisk). > > > > > > -- > > > Regards, > > > James Thomas > > > > > > > > -- > > Matt Sicker > > > > > > > > > > > > > -- > Matt Sicker -- Regards, James Thomas
Re: Updating our contributions guide
On Sat, 13 Jul 2019 at 22:07, Matt Sicker wrote: > > I've looked around for some existing guidelines around CLA > requirements, and so far I've found this: > > https://www.apache.org/licenses/contributor-agreements.html#clas > > So basically, the general idea I've seen is that small, trivial > changes do not require an ICLA, but anything non-trivial should > request one in order to establish provenance of the code over time. I've been looking at other larger ASF projects and can't find any reference to CLAs needed for contributions. This does seem to conflict with the advice on that page... Here's some examples: https://kafka.apache.org/contributing.html https://cordova.apache.org/contribute/contribute_guidelines.html https://github.com/apache/couchdb/blob/master/CONTRIBUTING.md I've also discovered this blog post (https://apetro.ghost.io/apache-contributors-no-cla/) which looks at this issue and links to a mailing list thread: http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E with the following passage... "We don't need a CLA on file to accept contributions from non-committers. We just need a clear intent by the author to contribute under our normal terms." There are other links in the blog post to ASF projects discussing this in the past and coming to the same conclusion. -- Regards, James Thomas
Re: Using Rust for the KnativeWhisk controller
+1 to what Matt has said. I've had this feedback multiple times from developers that the usage of Scala is a barrier to getting involved in the project. I understand the historical reasons for chosing Scala and realise the language does give us lots of benefits for stability & productivity once learnt. However, for new projects I'd +1 on using Go in the future. On Mon, 15 Jul 2019 at 17:20, Matt Rutkowski wrote: > IMO, one of the largest barriers to getting more (back-end) developers > into OW has been the use of Scala (sig. learning curve will not even > consider mounting) is by implementing in languages where the pool of active > developers is lower. It seems that nearly 100% of Serverless technology > "in the open" is being done in GoLang. If we wish to attract developers > from Knative, OpenFaaS, Kubeless, Fission, Fn, IronFunctions, etc., they > ALL use Go (which is not surprising as everyone is more-or-less looking at > a Kube stack, also Go, for CN apps with Serverless being a subset). > > Personally, after experiencing Go, for wskdeploy/CLI it was a joy to learn > (despite some tooling annoyances) and have listed it as a top requirement > developers training. In fact, I had assumed that as we seek to mainstream > on a Kube deployment we would want to unify around Go to continue to be > relevant in the Serverless developer community in order to lower the > barrier to entry/growth. > > My 2 cents. > > On 2019/07/15 09:58:58, "Michele Sciabarra" > wrote: > > Hello all, > > > > In my efforts to work a Kanative Whisk, I reached the point where I have > a kit with tekton-pipelines, knatve-serving building an actionlooop based > runtime. Now I need to implement a controller, in order to use the existing > wsk tooling. > > > > I know there is a prototype kwsk implementation made by redhat, written > in Go but looks like it is obsolete and unfinished, and to the best of my > knowledge, abandoned. > > > > I would like to resume the effort of writing an updated controller. I > actually already have a prototype using the Julia language. Julia is really > awesome, Python simplicity and Go speed, but I feed the community would > disagree on using Julia. Of course if I am wrong... let me know because > that would be my preferred choice. > > > > However, I feel that, given our Scala background, Rust would be a much > better choice for the KnativeWhisk controller. So I propose to use Rust > for the KwhiskController. > > > > What does the community think of the proposal? > > > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > -- Regards, James Thomas
Changing JavaScript SDK NPM Module Name: openwhisk => apache-openwhisk?
Reviewing the ASF guidelines on NPM packages to check our JS SDK satifises all the rules[1] - we're supposed to be publishing the NPM package as "apacheopenwhisk" and not "openwhisk". This NPM library was published at ( https://www.npmjs.com/package/openwhisk) before the project was donated to Apache. Moving from the library to publish at `apache-openwhisk` rather than `openwhisk`[2] is not technically challenging (and the new package name is available) but will cause numerous issues I'm asking for comments on what to do about this. Would like to engage the ASF mentors for advice as well. What does the community think about this? The library has significant usage (NPM tells me the library is averaging 6k downloads a week) using the existing package name. GitHub lists 38K references to the module. https://github.com/search?q=require%28%22openwhisk%22%29=Code All those external dependent projects, blog posts, documentation and tutorials, etc, that reference the library (and are outside of our control) will be reliant on the old package name. These will still work (as the old library version will still be available from NPM) but never receive new versions on installing the dependency. This may eventually mean the old library doesn't work with future platform changes and/or lead to security issues with outdated dependencies. I'm not sure if there's any leeway in the allowing the short-name for the NPM library (given we follow all the other requirements)? This will be a significant amount of work just changing all the references in project we control. If we do change the name - I'd assume `apache-openwhisk` is fine. Using `apacheopenwhisk` is slightly horrid [1] - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=109454613 [2] - following NPM JS module conventions - apache-openwhisk is much preferable than a single word (apacheopenwhisk). -- Regards, James Thomas
Re: devtools and make-quickstart
+1 on the first point. I've seen other issues in the past with the devtools project based on image versioning stuff. Given devtools is more for experimental and first-steps than production usage - switching to the standalone controller seems like a good idea. On Fri, 12 Jul 2019 at 16:15, Rodric Rabbah wrote: > this issue was opened against devtools and raises an important point: > https://github.com/apache/incubator-openwhisk-devtools/issues/273 > > "On a separate note, will these builds eventually be versioned or will they > continue to be tagged in a backwards incompatible way? I am trying to > create a build process that is deterministic and currently I am unable to > achieve this." > > Given that we're pointing developer to make quick start still as the way to > startup and some of the dependence in this build on docker latest (now > nightly), I think we should pin all the dependent images etc and make a > release available. > > An existential question is whether we should use the standalone controller > which is faster to startup and adapt our docs accordingly. > > Thoughts? > > -r > -- Regards, James Thomas
Re: Fine-grained permission
Protecting accidental overwritting or deletion of actions would be a great feature. I like the suggestion and approach of using Unix-style permissions. On Thu, 4 Jul 2019 at 07:25, Dominic Kim wrote: > Recently I discussed this: > https://github.com/apache/incubator-openwhisk/pull/4058 with my > colleagues. > That PR is to add a feature to protect actions from deletion by mistake. > That is a good suggestion and I think we can also include more generalized > way to handle the issue. > > For example, what we can expect about permission are as follows. > > 1. Action protection. > 2. Hide codes from the shared package. > > I am a bit faint but IIRC, Rodric suggested linux-like permission > management. > > Regarding number 1, we can achieve it with the permission, "Read / not > Write / Execute". > And with regared to number 2, we can also achieve it with the permission, > "not Read / not Write (this is the default of shared package action) / > Execute". > > If we apply linux-like permission to these cases, we can have two different > permission flags, one for owners, the other for users of shared packages. > Then actions can have permission information such as "71" or "51". > So "71" would mean the owner of an action can do "read/write/execute" it > but the one who uses the shared action would be able to do "not read/not > write/execute". > "51" would mean the owner can do "read/not write/execute". > > There might be more cases, but I believe we can deal with them in the same > way. > Any feedback or idea on this would be appreciated. > > Thanks > Best regards, > Dominic > -- Regards, James Thomas
Adding Github app (Depend-a-bot) to Client JS SDK repo?
Hello Whiskers. If I want to add a Github app to one of our repos - do I just need to open a JIRA ticket with Infra? Does anyone know if there are any rules about what apps are allowed? I'm continuing work[1] on updating the project dependencies for the Client JS SDK, which had not been updated for a long time. I want to make sure this doesn't happen again and add a Github app to send PRs each time a major dependency upgrade is available using Depend-a-bot: https://github.com/marketplace/dependabot-preview Does anyone have any issues with this? [1] - https://github.com/apache/incubator-openwhisk-client-js/pull/180 -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk Catalog (v0.10.0-incubating, rc1)
+1 [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 correct for each OpenWhisk repository. [x] All files have license headers as specified by OpenWhisk project policy [1]. [x] No compiled archives bundled in source archive. On Mon, 1 Jul 2019 at 05:37, Dominic Kim wrote: > +1 > > [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 correct for each OpenWhisk repository. > [x] All files have license headers as specified by OpenWhisk project > policy [1]. > [x] No compiled archives bundled in source archive. > > 2019년 7월 1일 (월) 오전 9:33, Carlos Santana 님이 작성: > > > +1 > > > > [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 correct for each OpenWhisk repository. > > [x] All files have license headers as specified by OpenWhisk project > > policy [1]. > > [x] No compiled archives bundled in source archive. > > > > On Sun, Jun 30, 2019 at 6:20 PM Rodric Rabbah wrote: > > > > > +1 > > > > > > [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 correct for each OpenWhisk > repository. > > > [x] All files have license headers as specified by OpenWhisk project > > > policy [1]. > > > [x] No compiled archives bundled in source archive. > > > > > > On Sun, Jun 30, 2019 at 3:34 PM David P Grove > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > This is a call to vote on releasing version 0.10.0-incubating release > > > > candidate rc1 of the following project module with artifacts built > from > > > the > > > > Git repositories and commit IDs listed below. > > > > > > > > * OpenWhisk Catalog: cb8d5c73 > > > > > > https://github.com/apache/incubator-openwhisk-catalog/commits/cb8d5c73 > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-catalog-0.10.0-incubating-sources.tar.gz > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-catalog-0.10.0-incubating-sources.tar.gz.asc > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-catalog-0.10.0-incubating-sources.tar.gz.sha512 > > > > > > > > This release is comprised of source code distribution only. > > > > > > > > You can use this UNIX script to download the release and verify the > > > > checklist below: > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > > > > > > > Usage: > > > > curl -s " > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > > > " -o rcverify.sh > > > > chmod +x rcverify.sh > > > > rcverify.sh openwhisk-catalog 'OpenWhisk Catalog' 0.10.0-incubating > rc1 > > > > > > > > Please vote to approve this release: > > > > > > > > [ ] +1 Approve the release > > > > [ ] 0 Don't care > > > > [ ] -1 Don't release, because ... > > > > > > > > Release verification checklist for reference: > > > > [ ] Download links are valid. > > > > [ ] Checksums and PGP signatures are valid. > > > > [ ] DISCLAIMER is included. > > > > [ ] Source code artifacts have correct names matching the current > > > > release. > > > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk > > repository. > > > > [ ] All files have license headers as specified by OpenWhisk > project > > > > policy [1]. > > > > [ ] No compiled archives bundled in source archive. > > > > > > > > This majority vote is open for at least 72 hours. > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md > > > > > > > > > > > > > -- > > Carlos Santana > > > > > -- Regards, James Thomas
OpenWhisk JS SDK Updates
Hello Whiskers. I'm started to work through the issue list on this repo ( https://github.com/apache/incubator-openwhisk-client-js/issues) at the moment. I've added some items I'm hoping to complete before a new release using the 3.20 tag on GitHub ( https://github.com/apache/incubator-openwhisk-client-js/milestone/1). If anyone has anything else they'd like to add - let me know and I can have a look... As the platform API is very stable, most of the issues relate to test fixes and CI/CD suggestions. There's also on-going issue of the (small) project dependencies needing regular updating (as NPM libraries publish at a constant rate). I've pushed a fix for the recent problem with package size: https://github.com/apache/incubator-openwhisk-client-js/issues/158 I'd like to add some checks to the CI/CD pipeline to catch this kind of issue again. https://github.com/apache/incubator-openwhisk-client-js/issues/159 This is in addition to starting to ship a "compiled" version of the library to NPM (https://github.com/apache/incubator-openwhisk-client-js/issues/160). This is really important as the library is pre-installed in every openwhisk JS runtime and smaller code-size is important for performance. *If anyone could help with code reviews on the upcoming PRs this would be really helpful! It's just simple Node.js code changes - none of that complex Scala stuff ;) If you're interested in helping out here - let me know and I can add you a a reviewer on the PRs. * -- Regards, James Thomas
Re: Openwhisk in a standalone runnable jar (#4516)
>> java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar > > > > > >> > > > > > >> You can use the default guest and whisk.system credentials to > > interact > > > > > >> with it. I am in the process of writing a readme for various > > options > > > > > >> exposed. Hope to get it done by Monday > > > > > >> > > > > > >> Chetan Mehrotra > > > > > >> > > > > > >>> On Fri, Jun 21, 2019 at 4:57 PM Nick Mitchell < > > moose...@gmail.com> > > > > > wrote: > > > > > >>> > > > > > >>> thanks chetan for doing this! > > > > > >>> > > > > > >>> could you provide some example startup sequences, e.g. with > > sample > > > > > configs? > > > > > >>> i'm willing to try this out for our CI/CD pipeline -- i'm sick > > of 1) > > > > > >>> waiting 5-7 minutes for openwhisk to start up; and b) fighting > > ansible > > > > > >>> versus xenial :) > > > > > >>> > > > > > >>> @starpit > > > > > >>> > > > > > >>> On Fri, Jun 21, 2019 at 12:44 AM Chetan Mehrotra < > > > > > chetan.mehro...@gmail.com> > > > > > >>> wrote: > > > > > >>> > > > > > >>>>> What's the performance like on startup time > > > > > >>>> > > > > > >>>> It starts in < 5 secs. > > > > > >>>> > > > > > >>>> So far no major blocking issue apart from fetching docker logs > > on Mac. > > > > > >>>> Current approach of directly reading the log json does not > > work. So > > > > > >>>> need to have a mac version which uses `docker logs` command to > > > > > >>>> somewhat handle such a case. > > > > > >>>> > > > > > >>>> Chetan Mehrotra > > > > > >>>> > > > > > >>>>> On Thu, Jun 20, 2019 at 9:50 PM James Thomas < > > jthomas...@gmail.com> > > > > > wrote: > > > > > >>>>> > > > > > >>>>> That is mind-blowingly cool! > > > > > >>>>> > > > > > >>>>> What's the performance like on startup time? > > > > > >>>>> > > > > > >>>>> On Thu, 20 Jun 2019 at 06:14, Carlos Santana < > > csantan...@gmail.com> > > > > > >>>> wrote: > > > > > >>>>>> > > > > > >>>>>> Genius! > > > > > >>>>>> https://www.adminsub.net/tcp-udp-port-finder/whisker > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> - Carlos Santana > > > > > >>>>>> @csantanapr > > > > > >>>>>> > > > > > >>>>>>> On Jun 19, 2019, at 12:30 PM, David P Grove < > > gro...@us.ibm.com> > > > > > >>>> wrote: > > > > > >>>>>>> > > > > > >>>>>>> WhiskerControl > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -- > > > > > >>>>> Regards, > > > > > >>>>> James Thomas > > > > > >>>> > > > > > > > -- Regards, James Thomas
Tech Interchange Call on Wednesday: Topics?
Does anyone have anything for the meeting on Wednesday? I can add you to the agenda as I'm running the call. I know there's lots of exciting stuff going on from the mailing list so if anyone wants to share on the call - let me know! -- Regards, James Thomas
Re: [DISCUSS] - prepare to release OpenWhisk catalog
+1 to everything Rodric said! On Mon, 17 Jun 2019 at 14:07, Rodric Rabbah wrote: > > If the weather package is functional and can run with newer node kinds then > I’d favor keeping it. > > I’d favor removing the combinators as we have composer now and we didn’t > document them properly (my fault). > > I would consider removing the bash installers since they’re redundant with > the wsk deploy manifest. > > I’m indifferent on version number. > > -r > > > On Jun 17, 2019, at 8:57 AM, David P Grove wrote: > > > > > > > > As Rodric mentioned in [1], the catalog is the last package we need to > > release before we can start on the main repo. > > > > This is a discussion thread to figure out what (if anything) needs to be > > done before we can start the release process. Here are three questions I > > have: > > > > 1. Should we remove the Weather Company package and let interested users > > get it from a downstream IBM repo, or is this a generally useful package > > that we should provide in the Apache release (like Slack and Github)? > > > > 2. Should we remove the combinator package? (It is marked as deprecated in > > the package install scripts). I think the functionality is now better > > provided by Apache OpenWhisk composer, but I don't know the full history of > > this package. > > > > 3. Should this release be numbered 0.10.0 or 1.0.0? > > > > --dave > > > > [1] > > https://lists.apache.org/thread.html/ddf47c05e72426a47f0a414e1dd68cc6075fa4a60be1753318ebfe58@%3Cdev.openwhisk.apache.org%3E -- Regards, James Thomas
Re: openwhisk distributions via dockerhub
On Wed, 19 Jun 2019 at 20:44, David P Grove wrote: > > 3. Once we have addressed (1) and (2), we should consider opening a legal > discuss thread to see if we can continue to use /u/openwhisk (with clear > branding that /u/openwhisk is an official distribution channel from the > Apache OpenWhisk (P)PMC) or if we must migrate to /u/apacheopenwhisk or > similar. If that discussion leads us to believe `openwhisk` must be retired in favour the full project name, this will also affect the NPM module for the JS Client SDK. https://www.npmjs.com/package/openwhisk Looking over the NPM guidelines from ASF, we comply with all of them apart from the name. I've opened an issue to track this and will wait on the legal discussion. https://github.com/apache/incubator-openwhisk-client-js/issues/169 -- Regards, James Thomas
Re: Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution
+1 on either Dave or Rodric taking the chair. Both are excellent candidates and ideally suited to the role. On Wed, 19 Jun 2019 at 20:56, David P Grove wrote: > > Rodric Rabbah wrote on 06/19/2019 06:39:19 AM: > > > > A one year rotation makes sense to me. > > Big +1 on planning for rotation. > > > I’d like to nominate Dave Grove for consideration. > > Thanks Rodric. I'm happy to take a turn at some point. Whether that's > soon or a couple years down the road doesn't matter to me. > > -dave -- Regards, James Thomas
Re: Openwhisk in a standalone runnable jar (#4516)
That is mind-blowingly cool! What's the performance like on startup time? On Thu, 20 Jun 2019 at 06:14, Carlos Santana wrote: > > Genius! > https://www.adminsub.net/tcp-udp-port-finder/whisker > > > - Carlos Santana > @csantanapr > > > On Jun 19, 2019, at 12:30 PM, David P Grove wrote: > > > > WhiskerControl -- Regards, James Thomas
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
+1 Apache OpenWhisk should graduate. This is long overdue! On Wed, 5 Jun 2019 at 17:21, Matt Hamann wrote: > > This is awesome! > > +1 for me. Let's graduate! > > > -Matt > matthew.ham...@gmail.com > > > On Wed, Jun 5, 2019 at 11:16 AM Vincent S Hou wrote: > > > Thank all the great efforts by OpenWhisk contributors. It is time for us > > to graduate. > > All the official modules, like openwhisk core, catalog, cli, runtimes, > > etc, have successfully gone through one or multiple releases under Apache > > as incubator. > > We have been familiar with all the legal processes of Apache. The modules > > have been mature enough to evolve as top level project. > > > > I vote: +1 Apache OpenWhisk should graduate. > > > > > > 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: +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/04/2019 05:26PM > > Subject: [EXTERNAL] [VOTE] Apache OpenWhisk graduation to Top Level Project > > > > Hi all, > > > > After a discussion among the Apache OpenWhisk community on the dev > > mailing list [1], we have completed all Trademark transfers, and we > > are now in the process of pruning the PMC roster, completing the > > podling status page and completing the project maturity model [2]. > > > > Apache OpenWhisk entered the incubator on November 23 2016. Since > > then, we have grown to be in the top 25 list of Apache projects by > > GitHub Stars at 4041, have 229 unique contributors across all our > > project repos, more than 2500 commits, and most importantly, our > > community has grown and is diversified beyond the initial founding > > contributors and organization. > > > > The project has come a long way in embracing The Apache Way, in no > > small part to our dedicated mentors and the community spirit that has > > grown along this journey. We are operating well as an Apache project > > and so we should take the next step. > > > > As such, I am calling a vote for Apache OpenWhisk to graduate to a top > > level project. If we agree that we should graduate to a top level > > project, the next step will be to draft a Resolution [3] for the PPMC > > and IPMC to vote upon. > > > > Please take a minute to vote on whether or not Apache OpenWhisk should > > graduate to a Top Level Project by responding with one of the > > following: > > > > [ ] +1 Apache OpenWhisk should graduate. > > [ ] +0 No opinion > > [ ] -1 Apache OpenWhisk should not graduate (please provide the reason) > > > > The VOTE is open for a minimum of 72 hours. Per Apache guidelines [4] > > I will notify the incubator mailing list that a community vote is > > under way. > > > > Thank you. > > -r > > (on behalf of the Apache OpenWhisk PPMC) > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_8daa3a05148f54ca82458777e2b2b5e25ba99d39dcf8ce7dd85d0188-40-253Cdev.openwhisk.apache.org-253E=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=LUNmCHjmrhrkjp9ZF9fhwg=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o=Gnn9hS-jCq6kxpUkV5YDjAvpeSZ2W9p1_XFdfvkjIa4= > > [2] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_OPENWHISK_Project-2BMaturity-2BModel=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=LUNmCHjmrhrkjp9ZF9fhwg=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o=qtLpjM8ULRYiBYtOmML-UfW6byo2BgbC0Qaz9HSJubc= > > [3] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D115526932=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=LUNmCHjmrhrkjp9ZF9fhwg=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o=YGyPOxDTHT-HjpQZb1_UMuX4dySHKqv0FH0AkPlJjpg= > > [4] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_graduation.html-23community-5Fgraduation-5Fvote=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=LUNmCHjmrhrkjp9ZF9fhwg=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o=oYAfkquuRCiMbdk0S-TF9_IG9jFe1OYc-qtxFDjBf2Q= > > > > -- Regards, James Thomas
[RESULT][VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc2) apache-openwhisk x
The voting is now closed. The vote has PASSED with 4 +1 binding votes from Rodric Rabbah, Ying Chun Guo, Matt Rutkowski and Dave Grove and no +0 or -1 votes. I'll send the notice to the incubator mailing list to get the vote started there. On Thu, 30 May 2019 at 17:42, James Thomas wrote: > > Hello, > > This is a call to vote on releasing version 1.14.0-incubating release > candidate rc2 of the following project module with artifacts > built from the Git repositories and commit IDs listed below. > > * Apache OpenWhisk Runtime Node.js: 14d2af8 > https://github.com/apache/incubator-openwhisk-runtime-nodejs.git/commits/14d2af8 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > Usage: > curl -s > "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD; > -o rcverify.sh > chmod +x rcverify.sh > rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js' > 1.14.0-incubating rc2 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > > > > -- > Regards, > James Thomas -- Regards, James Thomas
[VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc2) apache-openwhisk x
Hello, This is a call to vote on releasing version 1.14.0-incubating release candidate rc2 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * Apache OpenWhisk Runtime Node.js: 14d2af8 https://github.com/apache/incubator-openwhisk-runtime-nodejs.git/commits/14d2af8 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below: https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD Usage: curl -s "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD; -o rcverify.sh chmod +x rcverify.sh rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js' 1.14.0-incubating rc2 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers if necessary. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc2)
passed > > > verifying sources have proper headers... passed > > > scanning for executable files... passed > > > scanning for non-text files... passed > > > scanning for archives... passed > > > scanning for packages... passed > > > > > > run the following command to remove the scratch space: > > > > > > On Wed, May 29, 2019 at 5:50 PM David P Grove wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > As discussed in [2], there was a regression in rc1 of > > apigateway. > > > > so > > > > we needed to generate a new release candidate once the fix had been > > > merged. > > > > That has been done. Therefore... > > > > > > > > This is a call to vote on releasing version 0.10.0-incubating release > > > > candidate rc2 of the following project module with artifacts built from > > > the > > > > Git repositories and commit IDs listed below. > > > > > > > > * OpenWhisk API Gateway: a737552c > > > > > > > > > > > > > https://github.com/apache/incubator-openwhisk-apigateway/commits/a737552c > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 > > > > > > > > This release is comprised of source code distribution only. > > > > > > > > You can use this UNIX script to download the release and verify the > > > > checklist below: > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > > > > > > > Usage: > > > > curl -s " > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > > > " -o rcverify.sh > > > > chmod +x rcverify.sh > > > > rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' > > > 0.10.0-incubating > > > > rc2 > > > > > > > > Please vote to approve this release: > > > > > > > > [ ] +1 Approve the release > > > > [ ] 0 Don't care > > > > [ ] -1 Don't release, because ... > > > > > > > > Release verification checklist for reference: > > > > [ ] Download links are valid. > > > > [ ] Checksums and PGP signatures are valid. > > > > [ ] DISCLAIMER is included. > > > > [ ] Source code artifacts have correct names matching the current > > > > release. > > > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk > > repository. > > > > [ ] All files have license headers as specified by OpenWhisk project > > > > policy [1]. > > > > [ ] No compiled archives bundled in source archive. > > > > > > > > This majority vote is open for at least 72 hours. > > > > > > > > > > > > [1] > > > > > > > > > > > > > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md > > > > [2] > > > > > > > > > > > > > https://lists.apache.org/thread.html/3a33c365fb755f364385bff06ac681912fd1af7a43a9b58a881d6b85@%3Cdev.openwhisk.apache.org%3E > > > > > > > > > -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc1)
g notice... failed (cat > > '/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA/incubator-openwhisk-apigateway-0.10.0-incubating/NOTICE.txt') > verifying license... passed > verifying sources have proper headers... passed > scanning for executable files... passed > scanning for non-text files... passed > scanning for archives... passed > scanning for packages... passed > > run the following command to remove the scratch space: > rm -rf '/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA' > > penguin [runtimes *] tools> cat > > '/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA/incubator-openwhisk-apigateway-0.10.0-incubating/NOTICE.txt' > Apache OpenWhisk API Gateway > Copyright 2016-2019 The Apache Software Foundation > > This product includes software developed at > The Apache Software Foundation (http://www.apache.org/). > > > MIT License > > > The following components are provided under the MIT License. See project > link for details. > > (MIT License) fakengx (bsm/fakengx - https://github.com/bsm/fakengx) > (MIT License) fakeredis (catwell/fakeredis - > https://github.com/catwell/fakeredis) > > On Mon, May 20, 2019 at 3:03 PM David P Grove wrote: > > > > > > > Hi, > > > > This is a call to vote on releasing version 0.10.0-incubating release > > candidate rc1 of the following project module with artifacts built from > the > > Git repositories and commit IDs listed below. > > > > * OpenWhisk API Gateway: 1f46de9 > > > https://github.com/apache/incubator-openwhisk-apigateway/commits/1f46de9 > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 > > > > This release is comprised of source code distribution only. > > > > You can use this UNIX script to download the release and verify the > > checklist below: > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > > > Usage: > > curl -s " > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > " -o rcverify.sh > > chmod +x rcverify.sh > > rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' > 0.10.0-incubating > > rc1 > > > > NOTE: The NOTICE.txt file will be reported as a failed by rcverify.sh. > > This is a known gap in rcverify.sh [2], not an issue with this release > > candidate. Please verify the NOTICE.txt file manually. > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > Release verification checklist for reference: > > [ ] Download links are valid. > > [ ] Checksums and PGP signatures are valid. > > [ ] DISCLAIMER is included. > > [ ] Source code artifacts have correct names matching the current > > release. > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > > [ ] All files have license headers as specified by OpenWhisk project > > policy [1]. > > [ ] No compiled archives bundled in source archive. > > > > This majority vote is open for at least 72 hours. > > > > > > [1] > > > > > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md > > [2] https://github.com/apache/incubator-openwhisk-release/issues/281 > > > -- Regards, James Thomas
[DISCUSS] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)
Further to the previous email thread, does anyone have anything they want to add about a potential release for the Apache OpenWhisk Runtime Node.js? The main feature I want to get out in this release is Node.js v12 support. I'll wait a few days before re-opening the VOTE thread. https://github.com/apache/incubator-openwhisk-runtime-nodejs/commit/386b13d5642e7e8d9dee00913fc97d529c9637ef -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)
Thanks for the clarification Betrand. I'd actually thought I'd opened a DISCUSS already (but obviously not...). I did want to do this, will send it out now. On Sat, 18 May 2019 at 09:13, Bertrand Delacretaz wrote: > Hi, > > On Fri, May 17, 2019 at 6:42 PM Carlos Santana > wrote: > > ...I didn’t see a [DISCUSS] thread before this [VOTE] thread.. > > Discuss threads are not a requirement, but if you actually have > something to discuss it's fair to ask for that of course. > > Or, this pPMC could make them required *for this project* but I don't > think that has happened. And if it has we need an URL that documents > it. > > > ...This are the type of things that the board will be looking for > > graduation criteria... > > The Incubator PMC (it's not the Board who looks at these details) is > not going to ask for those, > http://www.apache.org/legal/release-policy.html#release-approval lists > what's required for releases. > > -Bertrand > -- Regards, James Thomas
[VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)
Hello, This is a call to vote on releasing version 1.14.0-incubating release candidate rc1 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * Apache OpenWhisk Runtime Node.js: 3bf5268https://github.com/apache/incubator-openwhisk-runtime-nodejs.git/commits/3bf5268 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below:https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD Usage: curl -s "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD; -o rcverify.sh chmod +x rcverify.sh rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js' 1.14.0-incubating rc1 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers if necessary. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. -- Regards, James Thomas
Re: Change the way the java runtime handles envirorment variable
I'd definitely prefer to see us have a more generic discussion on changing
all runtimes to provide the context as an invocation parameter, rather than
having per-runtime fixes. This doesn't affect the invokers AFAIK.
Moving to providing a second `context` argument would have the advantage of
mirroring other serverless platforms, e.g. AWS Lambda.
exports.*myHandler* = function(event, context, callback) {
*... function code*
callback(null, "some success message");
// or
// callback("some error type");
}
On Thu, 2 May 2019 at 18:11, Rodric Rabbah wrote:
> I agree that any such change doesn’t need to touch the invoker except to
> potentially remove one variable from the environment (api host).
>
>
> -r
>
> > On May 2, 2019, at 12:11 PM, Tyson Norris
> wrote:
> >
> > FWIW, I don't think of this as a huge change, meaning no change is
> required at invoker/controller. Rather it is just a convention for context
> value access within functions and function signature that is already unique
> to each language runtime, and requires possibly supporting 2 runtimes per
> language+convention while transitioning to the new convention. This
> convention is exposed to function developers so "replacing it" is not
> really an option, I think, but rather requires graceful deprecation and
> migration (with developers participation).
> >
> > e.g. for nodejs, the old convention used for signature and context is:
> > - function signature is ` (args)`
> > - context is `process.env.`
> >
> > New convention for signature and context is:
> > - function signature is ` (contextObject, args)`
> > - context is ` contextObject.`
> >
> > So you can feasibly:
> > * create a new runtime for nodejs that uses new convention
> > * add a separate kind for using the new runtime
> > * gradually phase out use of old kind (communication, deprecation, etc)
> >
> > I just want to throw this out there because I get the feeling whenever
> we discuss "context" that there is misconception around the need to change
> the invoker to support this. There is surely some parts of the
> invoker/action container protocol that may be further cleaned up to isolate
> static values (action name) from per-activation context (activation id),
> but I don't think that is required to start changing the conventions for
> function signature to include context as a separate object from activation
> params.
> >
> > Thanks
> > Tyson
> >
> >
> > On 5/2/19, 8:54 AM, "David P Grove" wrote:
> >
> >
> >
> >Rodric Rabbah wrote on 05/02/2019 11:05:35 AM:
> >>
> >> any existing java function that uses the environment variables would
> have
> >> to be modified.
> >> i would not change it - openwhisk has a uniform model across all the
> >> runtimes and this would start to diverge... i can be convinced but
> >instinct
> >> is to leave it alone.
> >>
> >
> >I think the change could be justified if it was part of a broader
> redesign
> >to enable concurrent activations in a runtime.
> >1. pass in a context object instead of stashing
> activation-specific
> >params in the environment
> >2. require proper structured logging
> >
> >--dave
> >
> >
>
--
Regards,
James Thomas
Re: Move default Node.js runtime to v10?
PR is now open for this: https://github.com/apache/incubator-openwhisk/pull/4466 On Sat, 20 Apr 2019 at 16:09, Carlos Santana wrote: > +1 to move to nodejs10 > > - Carlos Santana > @csantanapr > > > On Apr 19, 2019, at 3:03 PM, Rodric Rabbah wrote: > > > > This is the catalog actions related issue that I opened at the time I > > tried: https://github.com/apache/incubator-openwhisk-catalog/issues/294 > > > > Some of the actions which require packages available in the node6 runtime > > fail in the newer node10 because we don't bundle any packages. So those > > actions have to "zip" up their dependencies. The patch that was made was > to > > pin the catalog actions to node6 with the project deploy configuration. > So > > my assessment is that we can flip the default once again and should be OK > > this time... but the catalog actions that are pinned to node6 will need > to > > be updated in a second phase. > > > > -r > > > > > > > >> On Thu, Apr 18, 2019 at 12:52 PM James Thomas > wrote: > >> > >> On Wednesday's community call I asked about moving the default Nodejs > >> version in the project to v10. > >> > >> Node.js 6 (which is the current default version) reaches "end of life" > on > >> April 30th according to https://github.com/nodejs/Release. Node.js 10 > is > >> the current LTS version and is supported until April 2021. > >> > >> Rodric mentioned this was started previously but ran into issues with > the > >> providers? > >> https://github.com/apache/incubator-openwhisk/issues/4265 > >> > >> Does anyone have any issues with going forward with this work (once any > >> issues have been resolved)? I see there is some work going on to fix the > >> failures (https://github.com/apache/incubator-openwhisk/pull/4450) > >> > >> -- > >> Regards, > >> James Thomas > >> > -- Regards, James Thomas
Apache OpenWhisk Web Action HTTP Proxy
Hello Whiskers. I wanted to share an experiment I built recently to run existing web apps on openwhisk (with minimal changes) using custom Docker images support. https://github.com/jthomas/openwhisk-web-action-http-proxy It uses a HTTP proxy binary inside the runtime container to proxy incoming Web Action requests to the web apps run on a different port inside the same container. HTTP responses are returned to the platform as Web Action responses. For simple & stateless web apps - it worked better than I thought. Here's an example of how to use this with an exsting Node.js+Express Web App: https://github.com/jthomas/openwhisk-web-action-http-proxy#nodejs--express-example $ git clone https://github.com/jthomas/express_example $ cd express_example & npm install $ zip -r action.zip * $ wsk action create --docker jamesthomas/generic_node_proxy --web true --main "npm start" -p "__ow_proxy_port" 3000 web_app action.zip $ wsk action get web_app --url Two different options are available for getting web application source files into the runtime environment - runtime injection using zip files or putting source files directly into the runtime image. There's lots more details about the project in the project README and I've now written a blog post in more details about the project here: http://jamesthom.as/blog/2019/04/29/apache-openwhisk-web-action-http-proxy/ -- Regards, James Thomas
Remove SDK commands from CLI?
Does anyone have any objections to removing the "SDK" command from the wsk cli? I came across this "feature" again recently due to a user running into issues trying to use docker support in the platform. I've recently been updating the docs on the docker actions and think we should remove this command as it doesn't represent best practice for the platform anymore. The SDK was an old solution to utilising custom runtime images in the beginning of the project, before the docker support improved a lot. The "SDKs" are a series of old tar files download from the external source repository. Looking at the Docker SDK, it does not represent a sensible approach to using binaries on the platform now we have the dockerskeleton image. I didn't investigate the Swift SDK and wouldn't be sure if this even works anymore I've never come across an external developer using these SDKs "in the wild" and can't see a valid use-case for continuing to provide them given all the changes in the platform since they were introduced. Does anyone have any comments? If not, I'll open a PR in the CLI to start removing them. -- Regards, James Thomas
Move default Node.js runtime to v10?
On Wednesday's community call I asked about moving the default Nodejs version in the project to v10. Node.js 6 (which is the current default version) reaches "end of life" on April 30th according to https://github.com/nodejs/Release. Node.js 10 is the current LTS version and is supported until April 2021. Rodric mentioned this was started previously but ran into issues with the providers? https://github.com/apache/incubator-openwhisk/issues/4265 Does anyone have any issues with going forward with this work (once any issues have been resolved)? I see there is some work going on to fix the failures (https://github.com/apache/incubator-openwhisk/pull/4450) -- Regards, James Thomas
OpenWhisk Client JS: Reducing Package Install Size?
Recent changes to the JS SDK ( https://github.com/apache/incubator-openwhisk-client-js/pull/147) led to an unfortunate issue where the new feature pulled in an external dependency which led to a significant increase in the install size for the NPM package. https://packagephobia.now.sh/result?p=openwhisk@3.19.0 Thanks to Nick Mitchell for spotting this and opening the issue to work out how best to fix this. https://github.com/apache/incubator-openwhisk-client-js/issues/158 Whilst we do still want to support HTTP/S proxies being used with the library, importing that external dependency directly is not a realistic solution due to the impact of all users. I've written up a few possible options and wanted to get community feedback before proceeding. Does anyone else have any other potential solutions or feedback on the suggetions? See the Github issue for details. Based on this problem, I've also opened some other issues to help make sure this kind of issue doesn't happen again <https://github.com/apache/incubator-openwhisk-client-js/issues/159> and also reduce build size <https://github.com/apache/incubator-openwhisk-client-js/issues/160> even further. Does anyone have any feedback on those proposals? -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.13.0-incubating, rc2)
+1 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 correct for each OpenWhisk repository. [x] All files have license headers if necessary. [x] No compiled archives bundled in source archive Logs from http://apache.jamesthom.as => verifying apache-openwhisk-1.13.0-incubating-rc2 fetching https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.13.0-incubating-rc2 checking the following files: openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz fetching https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS validaing release file archive: openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz fetching https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.13.0-incubating-rc2/openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz.asc fetching https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.13.0-incubating-rc2/openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz.sha512 fetching https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.13.0-incubating-rc2/openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) signature checking against public keys with ids: 72af0cc22c4cf320, 22907064147f886e, 44667bc927c86d51 file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) signed by key with id: 44667bc927c86d51 file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) calculated hash: e9b111cc28b61fd2a22fde7cf838f06301c4dd79e568169d62667c4dd8d5260c23446127406000e5930db6e89d4d50ed503b16549ac92f1793bcc03fe5fb5d2f file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) hash from file: e9b111cc28b61fd2a22fde7cf838f06301c4dd79e568169d62667c4dd8d5260c23446127406000e5930db6e89d4d50ed503b16549ac92f1793bcc03fe5fb5d2f file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) has no binary files in the archive file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) has no third party lib directories in the archive file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) DISCLAIMER.txt has valid contents: true file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) NOTICE.txt has valid contents: true file (openwhisk-runtime-go-1.13.0-incubating-sources.tar.gz) LICENSE.txt has valid contents: true On Sun, 7 Apr 2019 at 14:28, Rodric Rabbah wrote: > Hi, > > This is a call to vote on releasing version 1.13.0-incubating release > candidate rc2 of the following project module with artifacts > built from the Git repositories and commit IDs listed below. > > * OpenWhisk Runtime Go: ddd329946c1d061f256a274d6ccd23e527760e06 > > https://github.com/apache/incubator-openwhisk-runtime-go.git/commits/ddd329946c1d061f256a274d6ccd23e527760e06 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > Usage: > curl -s " > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD; > -o rcverify.sh > chmod +x rcverify.sh > rcverify.sh openwhisk-runtime-go 'OpenWhisk Runtime Go' 1.13.0-incubating > rc2 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current > release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > -- Regards, James Thomas
[RESULT][VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0.
Hello all, The vote for releasing Apache OpenWhisk Client JS (incubating) 3.19.0 is now closed. Vote result: 3 (+1 binding) (Bertrand Delacretaz, Sobkowiak Krzysztof, Matt Sicker) 0 ( 0 binding) (Justin Mclean) 0 (-1 binding) The vote has PASSED. Thank you everyone for taking the time to review the release and help us. Minor issues raised during the vote from members have been captured and will be fixed in the next release. -- Forwarded message - From: James Thomas Date: Tue, 26 Mar 2019 at 17:14 Subject: [VOTE]: Release Apache OpenWhisk Client JS (incubating) 3.19.0. To: Dear IPMC members, This is a call for vote to release Apache OpenWhisk Client JS (incubating) 3.19.0. The Apache OpenWhisk community has voted on and approved a proposal to release Apache OpenWhisk Client JS (incubating) 3.19.0. We now kindly request the Incubator PMC members to review and vote on this incubator release. Apache OpenWhisk (incubating) is a serverless, open source cloud platform that executes functions in response to events at any scale. OpenWhisk Client JS vote thread: https://lists.apache.org/thread.html/c891eb5543559d8894974ea39b11001e4302c1e3b0f11e47323af929@%3Cdev.openwhisk.apache.org%3E OpenWhisk Client JS vote result thread: https://lists.apache.org/thread.html/f0d56e810a0fe674f71f39b8e54b3de361dd1a9d8cb036446b070a12@%3Cdev.openwhisk.apache.org%3E This release comprises of source code distribution only. There is only one module within this release number 3.19.0. The artifact were built from the following Git commit IDs: - openwhisk-client-js: 726b982, The source code artifact of openwhisk client js can be found at: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz The SHA-512 checksum for the artifact of openwhisk client js is openwhisk-client-js-3.19.0-incubating-sources.tar.gz: 8D8FE6C5 48F5FE72 F5C5CC2E 1539416F 84B18BB7 D6A0075B 50CAFC22 55BFA27E C8E60B9D 6660E203 72CEB667 EAE91474 DAB16D8B 764B5141 8B7595DE 78CBA217 which can can be found via: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.sha512 The signature of the artifact of openwhisk client js can be found via: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.asc KEYS file is available here: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS We are currently using the tool called openwhisk-release ( https://github.com/apache/incubator-openwhisk-release) to release all the modules of OpenWhisk. The instruction for release managers can be found at: https://github.com/apache/incubator-openwhisk-release/blob/master/docs/release_instructions.md. This tool supports both manual and automated modes to package the source code, sign the artifacts and upload the artifacts into Apache SVN repositories. The vote will be open for at least 72 hours or until necessary number of votes are reached. Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove with the reason -- Regards, James Thomas -- Regards, James Thomas
Re: [DISCUSS] release openwhisk-client-js
I'm hoping to get to it today Shazron. We've now got enough votes from the Incubator ML to proceed... On Wed, 3 Apr 2019 at 02:31, Shazron wrote: > > Hi, is it possible for the vote to be closed and the package released? > Thanks! > > On Fri, Mar 15, 2019 at 1:28 AM Carlos Santana wrote: > > > +1 > > > > I think it make sense to make the version "3.19.0" > > > > Then after release pass, a convenient package can be posted to npm with a > > version that correlates with the previous one. > > > > We did the similar for runtimes > > > > -- Carlos > > > > On Thu, Mar 14, 2019 at 1:06 PM James Thomas wrote: > > > > > Hello whiskers. > > > > > > We want to do the first official apache release of the > > openwhisk-client-js > > > project. The project is very stable and doesn't change often, but we've > > now > > > had a few important PRs merge in the past month. > > > > > > https://github.com/apache/incubator-openwhisk-client-js/pull/147 > > > https://github.com/apache/incubator-openwhisk-client-js/pull/151 > > > https://github.com/apache/incubator-openwhisk-client-js/pull/152 > > > > > > I've opened a new PR to add the missing files necessary for a release. > > > https://github.com/apache/incubator-openwhisk-client-js/pull/154 > > > > > > Does anyone want to do anything before I cut the release? > > > > > > Speak now or forever hold your peace (until the next release...) > > > > > > -- > > > Regards, > > > James Thomas > > > > > > > > > -- > > Carlos Santana > > > > -- Regards, James Thomas
Re: Bi-weekly meeting tomorrow
Hey Tyson, I'd like to do a very short demo (5 mins...) of the new release verification tool I built (http://apache.jamesthom.as/) On Tue, 2 Apr 2019 at 17:15, Tyson Norris wrote: > > Hi Whiskers – > I plan to host the bi-weekly tech exchange meeting tomorrow – please send me > your agenda items! > > Call details: > Zoom: https://zoom.us/j/5043933185 > > Wednesday April 3rd > - 11AM EST(Eastern US) > - 5PM CET (Central Europe), > - 4PM UTC, 12AM CST (Beijing) > > > Thanks > Tyson -- Regards, James Thomas
Re: release verification help
On Tue, 26 Mar 2019 at 17:21, James Thomas wrote: > > On Mon, 25 Mar 2019 at 17:40, Carlos Santana wrote: > > > > Using the website I would think it doesn’t count as verifying the artifacts. > > > > Just playing devils advocate here. > > > > Going to a website and selecting something from a Dropbox and see green > > checks don’t know if the useful for the person doing the voting. Maybe > > taking the > code from the website or bash scripts and running locally > > seems more real. > > The tool is open-source and I'd encourage others to review the source > code to understand what it does and check for issues. If you are > concerned about using an external service, you can host the tool > yourself. > > -- > Regards, > James Thomas -- Regards, James Thomas
Re: [RESULT][VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
Hey Matt, I'm not sure about that - probably something to ask the mentors! ;) Dave Grove did tell me that dev-list votes from IPMC members roll over to the IPMC mailing list vote thread automatically, so you don't need to vote again. On Tue, 26 Mar 2019 at 18:53, Matt Sicker wrote: > > On Tue, 26 Mar 2019 at 12:07, James Thomas wrote: > > Non-binding +1: > > Matt Sicker > > I think this might be wrong now that I'm a mentor? Or does it only > apply to the IPMC vote? > > -- > Matt Sicker -- Regards, James Thomas
Re: release verification help
On Mon, 25 Mar 2019 at 17:40, Carlos Santana wrote: > > Using the website I would think it doesn’t count as verifying the artifacts. > > Just playing devils advocate here. > > Going to a website and selecting something from a Dropbox and see green > checks don’t know if the useful for the person doing the voting. Maybe taking > the > code from the website or bash scripts and running locally seems more > real. The tool is open-source and I'd encourage others to review the source code to understand what it does and check for issues. If you are concerned about using an external service, you can host the tool yourself. -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
Thanks Matt & Rodric for noticing those small issues. There's now two Github tickets to track resolving them and they will be in the next release. https://github.com/apache/incubator-openwhisk-client-js/issues/157 https://github.com/apache/incubator-openwhisk-client-js/issues/156 On Sun, 24 Mar 2019 at 12:57, Sobkowiak Krzysztof wrote: > +1 > > Best regards > > Krzysztof > > > On 18.03.2019 19:14, James Thomas wrote: > > This is to call for a vote for the release of Apache OpenWhisk Client JS > > (incubating) 3.19.0 > > > > List of JIRA ticket(s) resolved for this release can be found at > > > > https://issues.apache.org/jira/browse/INCUBATOR-232. > > > > This release comprises of source code distribution only. There is only > one > > module within this release number 3.19.0. The artifact were built from > the > > following Git commit IDs: > > > > - > > > > openwhisk-client-js: 726b982, > > > > The source code artifact of openwhisk client js can be found at: > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz > > > > The SHA-512 checksum for the artifact of openwhisk client js is > > openwhisk-client-js-3.19.0-incubating-sources.tar.gz: 8D8FE6C5 48F5FE72 > > F5C5CC2E 1539416F 84B18BB7 D6A0075B 50CAFC22 55BFA27E C8E60B9D 6660E203 > > 72CEB667 EAE91474 DAB16D8B 764B5141 8B7595DE 78CBA217 > > > > which can can be found via: > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.sha512 > > > > The signature of the artifact of openwhisk client js can be found via: > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.asc > > > > KEYS file is available here: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS > > > > Please vote on releasing this package as Apache OpenWhisk > > 3.19.0-incubating: OpenWhisk Client JS > > > > The vote will be open for at least 72 hours. > > > > [ ] +1 Release as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client JS > > > > [ ] +0 no opinion > > > > [ ] -1 Do not release and the reason > > > > Checklist for reference: > > > > [ ] Download links are valid. > > > > [ ] Checksums and PGP signatures are valid. > > > > [ ] DISCLAIMER is included. > > > > [ ] Source code artifacts have correct names matching the current > release. > > > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repo. > > > > [ ] All files have license headers if necessary. > > > > [ ] No compiled archives bundled in source archive. > > > > Thank you very much. > > > -- > Krzysztof Sobkowiak > > JEE & OSS Architect, Integration Architect > Apache Software Foundation Member (http://apache.org/) > Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/) > Apache Incubator PMC Member (https://incubator.apache.org/) > Senior Solution Architect @ Capgemini SSC > (http://www.capgeminisoftware.pl/) > -- Regards, James Thomas
[RESULT][VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
Hello. Thanks everyone for voting on the release of Apache OpenWhisk Client JS (incubating) 3.19.0 The vote is passed with 4 +1s (binding) and 4 +1s (non-binding). Binding +1: Carlos Santana Dave Grove Matt Rutkowski Rodric Rabbah Non-binding +1: Sobkowiak Krzysztof Ning Yougang Dominic Kim Matt Sicker There were no -1 or 0 votes. The vote has passed in the dev list of OpenWhisk, based on Apache voting policy. I am closing the vote mail thread, and will send out another email for IPMC to vote. -- Forwarded message - From: James Thomas Date: Mon, 18 Mar 2019 at 18:14 Subject: [VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0 To: This is to call for a vote for the release of Apache OpenWhisk Client JS (incubating) 3.19.0 List of JIRA ticket(s) resolved for this release can be found at https://issues.apache.org/jira/browse/INCUBATOR-232. This release comprises of source code distribution only. There is only one module within this release number 3.19.0. The artifact were built from the following Git commit IDs: - openwhisk-client-js: 726b982, The source code artifact of openwhisk client js can be found at: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz The SHA-512 checksum for the artifact of openwhisk client js is openwhisk-client-js-3.19.0-incubating-sources.tar.gz: 8D8FE6C5 48F5FE72 F5C5CC2E 1539416F 84B18BB7 D6A0075B 50CAFC22 55BFA27E C8E60B9D 6660E203 72CEB667 EAE91474 DAB16D8B 764B5141 8B7595DE 78CBA217 which can can be found via: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.sha512 The signature of the artifact of openwhisk client js can be found via: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.asc KEYS file is available here: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS Please vote on releasing this package as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client JS The vote will be open for at least 72 hours. [ ] +1 Release as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client JS [ ] +0 no opinion [ ] -1 Do not release and the reason Checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repo. [ ] All files have license headers if necessary. [ ] No compiled archives bundled in source archive. Thank you very much. -- Regards, James Thomas -- Regards, James Thomas
LICENSE format?
Should the LICENSE.txt files in the OpenWhisk project repos include the APPENDIX: How to apply the Apache License to your work. section as-is from http://www.apache.org/licenses/LICENSE-2.0.txt OR is it supposed to be applied following the instructions in those section, e.g. Copyright 2019 Some Name... We have a variety of styles in different repos and it's not clear which we should follow. https://github.com/apache/incubator-openwhisk-wskdeploy/blob/master/LICENSE.txt and https://github.com/apache/incubator-openwhisk-devtools/blob/master/LICENSE.txt Can someone with more experience in this provide guidance on which is correct? -- Regards, James Thomas
Re: release verification help
If anyone has any feature requests for http://apache.jamesthom.as please open issues @ https://github.com/jthomas/openwhisk-release-verification/issues PRs always welcome ;) It is just three (simple) Node.js openwhisk actions powering the backend to do the verification. On Mon, 25 Mar 2019 at 15:05, Chetan Mehrotra wrote: > Thanks Rodric and James for such tooling. This would greatly reduce the > friction in voting for releases. > > In Apache Sling we have evolved the voting process over the time [1] which > has helped in getting people to vote. > > Chetan Mehrotra > [1] > > https://sling.apache.org/documentation/development/release-management.html#starting-the-vote > > > On Mon, Mar 25, 2019 at 8:19 PM Rodric Rabbah wrote: > > > This email is in response to Chetan raising the following "May be we > > automate some of the steps using a shell script similar to > > > > > https://github.com/apache/sling-tooling-release/blob/master/check_staged_release.sh > > " > > in one of the recent release vote threads. > > > > Thanks to James Thomas, we have a web-based verification tool that > > automates the release candidate checks so it's much easier now to verify > > and vote on the releases. Source available at > > https://github.com/jthomas/openwhisk-release-verification and you can > try > > it out here http://apache.jamesthom.as/ per comment on Slack earlier > > today. > > > > And I opened a PR to add my bash scripts which I called `rcverify` here > > https://github.com/apache/incubator-openwhisk-release/pull/254. This was > > previously a gist which I'll delete if the PR is accepted (see [1] for > > reference). > > > > [1] rcverify gist > > https://gist.github.com/rabbah/0f9e138c9088758c30fe31f05b893041 > > > > -r > > > -- Regards, James Thomas
Re: [VOTE] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)
, and Package Kafka as described above. > > The vote will be open for at least 72 hours. > [ ] +1 Release Apache OpenWhisk Package Alarm, Package Cloudant, and > Package Kafka 2.0.0-incubating > [ ] +0 no opinion > [ ] -1 Do not release and the reason > > Checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > regards, > > --dave > -- Regards, James Thomas
Re: [Bi-Weekly Tech Interchange] Call for agenda topics
I'd like to show my new web action http proxy - 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 Dragos > To: dev@openwhisk.apache.org > Date: 03/19/2019 09:08 AM > Subject:[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://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_my_asfopenwhisk=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6V3FXFwHvE0SFE3N4Rk7-rlMhS2xkaqR1AlgZ0xtvKY=27x2jBqNcasvt0sohR9IvAJ_JZoi4YvKvgdtpOjxtRE=AXU7OQ9kktdXLKRBmyqhY63F-s7B-U3h2nElV5sk_WI= > > - Wednesday March 20th > 11AM EST(Eastern US) > 5PM CET (Central Europe), > 4PM UTC, 12AM CST (Beijing) > > Thanks, > dragos > > > > > -- Regards, James Thomas
Re: [VOTE] release Apache OpenWhisk CLI 0.10.0-incubating
+1 [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 correct for each OpenWhisk repository. [x] All files have license headers if necessary. [x] No compiled archives bundled in source archive. On Sat, 16 Mar 2019 at 18:57, David P Grove wrote: > > > This is a call to vote on releasing version 0.10.0-incubating of the Apache > OpenWhisk CLI. > > The Apache OpenWhisk CLI provides the command line tooling for interacting > with Apache OpenWhisk. > > This release comprises of source code distribution only. There are three > modules (git repos) included in this CLI release. All artifacts were built > by PR#249 in the openwhisk-release repo from the following Git commit IDs: > * openwhisk-cli: eaf64ae > * openwhisk-client-go: 4286a82 > * openwhisk-wskdeploy: 7d79fd7 > > openwhisk-cli (55BEEB6D CDF621AB 7AA6098A 5DBCA55E 6D7E3B0C A3DAA7DF > B44103F8 CE30ACC9 13411ECC BFF18519 3E142EC3 D27AA081 E1D47F63 14E9E708 > 90646EC7 C13756D6) > src.tar.gz: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-cli-0.10.0-incubating-sources.tar.gz > sha512 checksum: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-cli-0.10.0-incubating-sources.tar.gz.sha512 > signature: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-cli-0.10.0-incubating-sources.tar.gz.asc > > openwhisk-client-go (068DBC87 533905DB D0089CAE 74FD0B91 109992D8 D843CAA4 > 01EA87B6 9CDC9550 6D555655 4679FF36 7A52414E DCC59126 E558085D 3E960DEB > 18804581 6B2FA019) > src.tar.gz: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-client-go-0.10.0-incubating-sources.tar.gz > sha512 checksum: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-client-go-0.10.0-incubating-sources.tar.gz.sha512 > signature: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-client-go-0.10.0-incubating-sources.tar.gz.asc > > openwhisk-wskdeploy (412B1E09 129F2884 A1D4E9DE 0A979B47 55A54FC5 61E1D328 > 325E8A12 AE504779 A2350B9F 4185582F 7782EEA5 AE9018CD 52E4AA4C 484B5211 > AA449B4B 9F9E2432) > src.tar.gz: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-wskdeploy-0.10.0-incubating-sources.tar.gz > sha512 checksum: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-wskdeploy-0.10.0-incubating-sources.tar.gz.sha512 > signature: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-wskdeploy-0.10.0-incubating-sources.tar.gz.asc > > All release artifacts were signed with key 72AF0CC22C4CF320. > KEYS file is available here: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS > > How to verify the artifacts can be found at: > https://cwiki.apache.org/confluence/display/OPENWHISK/How+to+verify+the > +release+checklist+and+vote+on+OpenWhisk+modules+under+Apache > > Please vote on releasing the three components of Apache OpenWhisk CLI > 0.10.0-incubating as described above. > > The vote will be open for at least 72 hours. > [ ] +1 Release as Apache OpenWhisk 0.10.0-incubating: openwhisk-cli, > openwhisk-client-go, openwhisk-wskdeploy > [ ] +0 no opinion > [ ] -1 Do not release and the reason > > Checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > regards, > > --dave > -- Regards, James Thomas
[VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
This is to call for a vote for the release of Apache OpenWhisk Client JS (incubating) 3.19.0 List of JIRA ticket(s) resolved for this release can be found at https://issues.apache.org/jira/browse/INCUBATOR-232. This release comprises of source code distribution only. There is only one module within this release number 3.19.0. The artifact were built from the following Git commit IDs: - openwhisk-client-js: 726b982, The source code artifact of openwhisk client js can be found at: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz The SHA-512 checksum for the artifact of openwhisk client js is openwhisk-client-js-3.19.0-incubating-sources.tar.gz: 8D8FE6C5 48F5FE72 F5C5CC2E 1539416F 84B18BB7 D6A0075B 50CAFC22 55BFA27E C8E60B9D 6660E203 72CEB667 EAE91474 DAB16D8B 764B5141 8B7595DE 78CBA217 which can can be found via: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.sha512 The signature of the artifact of openwhisk client js can be found via: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.asc KEYS file is available here: https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS Please vote on releasing this package as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client JS The vote will be open for at least 72 hours. [ ] +1 Release as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client JS [ ] +0 no opinion [ ] -1 Do not release and the reason Checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repo. [ ] All files have license headers if necessary. [ ] No compiled archives bundled in source archive. Thank you very much. -- Regards, James Thomas
Re: [DISCUSS] graduation from the incubator
+100 on this. I think the project community has reached a level of maturity that would enable us to graduate according to the incubator guidelines. The level of community contributions on the mailing list and the slack channel are indicative of the succes of the project. We have a broad number of committers from different backgrounds and interests. From a technical perspective, I think the platform is also relatively stable and has multiple production users that have been running over multiple years. On Fri, 15 Mar 2019 at 22:06, David P Grove wrote: > > > I'd like to kick off a discussion to assess the project's readiness for > graduation from the incubator. > > Per Rodric's recent stats [1], the community has developed nicely in terms > of code contribution. > > We've released a number of software components following the Apache release > process. We are in the midst of making our first "uber-release" across all > of our sub-components (expect at least 2 voting threads next week). > > Overall I think the community is active. Communication on the project > slack is frequent (avg of >160 messages a day) and is now digested daily to > the dev list. (See [2] for stats). > > There are a couple procedural tasks we still need to complete, foremost > being the formal transfer of the OpenWhisk trademarks from IBM to the ASF. > But I think we can assume that these tasks will be completed and start > considering graduation in parallel. > > Please share your thoughts, > > --dave > > [1] > > https://lists.apache.org/thread.html/b2217c61caad5c7a0369699d06d44e5cf688d3cba982e354a45b8c78@%3Cdev.openwhisk.apache.org%3E > [2] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091999 > -- Regards, James Thomas
Re: [DISCUSS] Release event providers
+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 wrote: > > > > > > > > As part of the unified release, we will be doing the first Apache release > > of the OpenWhisk event providers (openwhisk-package-alarms, > > openwhisk-package-cloudant, openwhisk-package-kafka). > > > > I've taken a look at the pending PRs, and I think only the ones I just > > submitted to add DISCLAIMER.txt, etc. are release blocking. Please > comment > > if you disagree (or want to get in any other changes before a release). > > > > These components all have had non-Apache releases in the past, and thus > > have a history of version numbering that we need to not confuse. > > > > If we want to stick with the minimal increment under semvar, the initial > > Apache releases would be numbered: > >alarms: 1.12.5 > >cloudant: 1.9.4 > >kafka: 1.4.22 > > > > We could also decide to do a "major" bump to allow a clean Apache vs. > > non-Apache break in the version numbers. In other words, we would make > > this the 2.0.0 release of all three event provider modules. > > > > My strong inclination is to go with 2.0.0, but I would like to hear > > thoughts from others. Assuming there are no technical blockers, I would > > like to initiate a formal release process for these three components > early > > next week. > > > > thanks, > > > > --dave > -- Regards, James Thomas
Re: OpenWhisk Apps on Knative
ems under different scenarios > and > > measure what happens. > > > > Our current runtime system probably does need to evolve to better exploit > > Mesos/Kubernetes (eg Tyson's recent PR). Kubernetes itself is likely to > > evolve to better support FaaS-style workloads so we will be able to have > a > > thinner OpenWhisk-specific layer. I don't think we should expect every > > runtime system design decision we have made to hold constant as > technology > > evolves around us. But the system-level OpenWhisk runtime could > completely > > change without any disruption to the user-level programming model and > > developer tooling. For example, IBM Cloud Functions switched from a > > "classic" ansible-driven VM-based deployment to a Kubernetes-based > > deployment of OpenWhisk in the middle of 2018. None of our customers > > noticed or cared (from their perspective nothing changed and all their > > existing programs still run just fine). > > > > Finally, the focus of this project is where the community takes it. We > can > > even go multiple directions simultaneously. That's how open source works > :) > > > > > > --dave > -- Regards, James Thomas
Re: override main on activation?
This is an interesting idea. Lambda has a nice feature of being able to
create functions from an S3 file containing the source zip, which means you
don't have to upload the same code for each different function. Not having
something can make deployments unnecessarily long on OpenWhisk when you
have a large app with dozens of functions and large action packages.
If this was available - I wonder if there's a way to define an "action
clone" which is like a sym-link to another action with a different "main"
parameter (defined at create time)? It would allow us to upload the action
package once and then create sym-links for all the other actions. This
would dramatically speed up deployments and reduce the amount of code
needed to store in the backend.
On Fri, 15 Mar 2019 at 07:45, Michele Sciabarra
wrote:
> I like the idea. In particular, it would be very helpful in implementing
> an idea I had some time ago: deployment of Jupyter Notebooks as actions!
> (Here I refer to Python based notebooks mostly)
>
> Normally you have some code in it that you develop (and test)
> interactively, but the problem is: what is the entry point? Of course, it
> would be a "main" action defined in it but it would be limiting.
>
> In this way, I could pass the entire notebook to the initialization of the
> action and then invoke the various functions defined in it.
>
> --
> Michele Sciabarra
> mich...@sciabarra.com
>
> - Original message -
> From: Rodric Rabbah
> To: dev@openwhisk.apache.org
> Subject: override main on activation?
> Date: Friday, March 15, 2019 5:58 AM
>
> When one creates an action today, they can specify the main entry point at
> creation time. For example:
>
> wsk action create myfn f.js --main foo
>
> This allows a single file with multiple functions to be used as different
> actions.
>
> But this is wasteful - one has to create multiple actions this way and
> we're paying the cost in the backend by replicating the code (in the
> database, and multiple code fetches).
>
> What if the main was specified on invoke instead? For example, take a web
> action from this file hello.js
>
> function niam(args) { return { 'greetings': 'Hello from a
> non-standard entrypoint.' } } function main(args) { return {
> 'greetings': 'Hello from a standard entrypoint.' } }
>
> We could allow main to be set on the action activation.
>
> > curl -k https://guest.localhost/default/hello.json
> {
> "greetings": "Hello from a standard entrypoint."
> }
>
> And now with an override to "main", using @ as the new entry
> point.
>
> > curl -k https://guest.localhost/default/hello.json@niam
> {
> "greetings": "Hello from a non-standard entrypoint."
> }
>
> I created an issue to discuss the idea [1].
>
> I'm thinking primarily to restrict this to web actions initially, although
> there are some extensions that are also reasonable to consider
> subsequently:
>
>1. we could also make it work for POST invoke, namely wsk action invoke
>--main.
>2. we can extend it to sequences so that you can create a sequence from
>fn@main1, fn@main2
>3. we can further extend it to conductor continuations
>
> [1] https://github.com/apache/incubator-openwhisk/issues/4349
>
--
Regards,
James Thomas
Re: Pluggable Trigger Feed Event Provider
I've now opened an infrastructure ticket to move the pluggable event provider back into Apache OpenWhisk. https://issues.apache.org/jira/browse/INFRA-18011 Once this is done and the repo is ready, I'll work on migrating the S3 plugin back upstream too. On Sat, 9 Feb 2019 at 16:29, Rodric Rabbah wrote: > This is awesome. Thanks James for sharing it. > > -r > > > On Feb 8, 2019, at 12:11 PM, James Thomas wrote: > > > > Hello Whiskers. > > > > On Wednesday's Community Call, I presented my work on building a > "pluggable > > trigger feed event provider". The background for this experiment was > > needing to build another trigger feed event source without having to > > replicate all the boilerplate needed for trigger management. > > > > Here is the presentation from the call: > > > https://speakerdeck.com/jthomas/apache-openwhisk-pluggable-event-providers > > Video recording of the call is available on the OpenWhisk YouTube > channel: > > https://www.youtube.com/watch?v=krm7X5YpGy0 > > > > Feedback on the call was very positive so I've pushed the code to an > > external Github repo allowing others to have a look at how it works. > > > > This is the repo for the "generic event feed provider". The README > contains > > all the instructions on how to create a plugin and run the provider with > a > > pluggable event source. > > > > https://github.com/jthomas/openwhisk-pluggable-event-provider > > > > Here's an example event plugin I built for an S3-compatible object store. > > It polls a bucket endpoints and compares file etags, stored in Redis, to > > determine any file changes. Triggers are fired with file events. > > > > https://github.com/jthomas/openwhisk-s3-trigger-feed > > > > As discussed on the call, my next steps were > > > > - > > > > Make the code public for the community to evaluate. (DONE ✅) > > - > > > > Write a few more plugin providers (RabbitMQ, MQTT) to test it further. > > - > > > > Contribute the code back to Apache to become an official component of > > the project. > > > > All feedback welcome! > > -- > > Regards, > > James Thomas > -- Regards, James Thomas
[DISCUSS] release openwhisk-client-js
Hello whiskers. We want to do the first official apache release of the openwhisk-client-js project. The project is very stable and doesn't change often, but we've now had a few important PRs merge in the past month. https://github.com/apache/incubator-openwhisk-client-js/pull/147 https://github.com/apache/incubator-openwhisk-client-js/pull/151 https://github.com/apache/incubator-openwhisk-client-js/pull/152 I've opened a new PR to add the missing files necessary for a release. https://github.com/apache/incubator-openwhisk-client-js/pull/154 Does anyone want to do anything before I cut the release? Speak now or forever hold your peace (until the next release...) -- Regards, James Thomas
Re: change the default action context to omit api key
This makes sense from a security POV. Given the potential for breaking user applications[1] - we should try to document this as widely as possible. It could probably do with a blog post. I've opened an issue to add this to the JS SDK itself - https://github.com/apache/incubator-openwhisk-client-js/issues/146 [1] - Existing demo apps which a new user might deploy and uses the SDK won't work. On Tue, 19 Feb 2019 at 15:24, Rodric Rabbah wrote: > Thanks to all the input here and on the PR - I think we ended up somewhere > positive. Here's a summary: > > 1. for pre-existing actions that are already deployed, they're > grandfathered in and will continue to behave in a way where they receive > the api key on activation. This is done by detecting the absence of the new > annotation. > 2. the annotation is added on newly created actions only. > 3. on update of pre-existing actions, the annotation is not added. > > The latest code which now passes all the previous and tests (for backward > compatibility is here): > https://github.com/apache/incubator-openwhisk/pull/4284 > > -r > > > On Thu, Feb 14, 2019 at 9:37 PM Rodric Rabbah wrote: > > > I've implemented changes to the PR > > https://github.com/apache/incubator-openwhisk/pull/4284 for backward > > compatibility --- such that, actions which do not have the annotation > will > > still get the api key injected. > > > > The annotation is added by the controller when an action is created or > > updated unless already present. The default value for the annotation is > > "false", meaning no key is injected to the action context. > > > > Furthermore comments and feedback is appreciated. > > > > -r > > > -- Regards, James Thomas
Re: Bi-Weekly Tech Interchange tomorrow - add agenda topics here
Erez & Matt - that's fine - I'll add you both. On Tue, 19 Feb 2019 at 15:48, Matt Rutkowski wrote: > Priti and I would like to share our progress, findings and plans for > making our OpenWhisk runtimes work (NodeJS primarily) with Knative (build > and serving) with minimal impacts with the hopes it will get our comm. > thinking about what are the essential differentiators of OW to carry > forward on a Kube/Knative stack. > > Kind regards, > Matt > > > > From: James Thomas > To: dev@openwhisk.apache.org > Date: 02/19/2019 06:01 AM > Subject:Re: Bi-Weekly Tech Interchange tomorrow - add agenda > topics here > > > > That should be "Wednesday (February 20th)." > > On Tue, 19 Feb 2019 at 11:55, James Thomas wrote: > > > Hi, > > > > Please add to this thread any agenda items you'd like to discuss at the > > Tech Interchange call tomorrow - Wednesday (February 19th). > > > > Call details: > > > > Web Meeting: Tech Interchange (bi-weekly): > > - Day-Time: Wednesdays, 11AM EST(Eastern US), 5PM CET (Central Europe), > > 4PM UTC, 12AM CST (Beijing) > > - Zoom: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_my_asfopenwhisk=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=EjhW8S-FqgHC1fjj5A000Vec_CnxYfUZLjxLz4VBR0o=MtC2AY2iR-Rek_ED143FEsuYjmlFxPs9W1m3dALg1Yo= > > > > > -- > > Regards, > > James Thomas > > > > > -- > Regards, > James Thomas > > > > > -- Regards, James Thomas
Re: switch docker compose to "lean"?
That makes sense. I see a lot of people having issues with the quick-start due to the number of components. Would need to document this change and explain how to change back as well. On Sat, 16 Feb 2019 at 22:56, Carlos Santana wrote: > Yes +1 make compose lean > > - Carlos Santana > @csantanapr > > > On Feb 16, 2019, at 1:21 PM, Rodric Rabbah wrote: > > > > A PR we recently merged add the ability to deploy openwhisk in a lean > > configuration - without kafka/zookeeper (thanks Pavel!). Should the make > > quick-start target for docker compose use it by default? > > > > I'm trying to reproduce failures reported in the slack channel for > > docker-compose/make quick-start and it occurred to me we can startup even > > faster with the lean configuration. > > > > -r > -- Regards, James Thomas
Re: Bi-Weekly Tech Interchange tomorrow - add agenda topics here
That should be "Wednesday (February 20th)." On Tue, 19 Feb 2019 at 11:55, James Thomas wrote: > Hi, > > Please add to this thread any agenda items you'd like to discuss at the > Tech Interchange call tomorrow - Wednesday (February 19th). > > Call details: > > Web Meeting: Tech Interchange (bi-weekly): > - Day-Time: Wednesdays, 11AM EST(Eastern US), 5PM CET (Central Europe), > 4PM UTC, 12AM CST (Beijing) > - Zoom: https://zoom.us/my/asfopenwhisk > > -- > Regards, > James Thomas > -- Regards, James Thomas
Bi-Weekly Tech Interchange 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 - Wednesday (February 19th). Call details: Web Meeting: Tech Interchange (bi-weekly): - Day-Time: Wednesdays, 11AM EST(Eastern US), 5PM CET (Central Europe), 4PM UTC, 12AM CST (Beijing) - Zoom: https://zoom.us/my/asfopenwhisk -- Regards, James Thomas
Re: nodejs runtime packages in base images
-1 on this I'm afraid. I agree with everything Carlos said - I think the maintance and security burden of rolling packages into the base layers outweights the ease of use concern for new users. On Sat, 16 Feb 2019 at 14:13, Carlos Santana wrote: > > With my vendor hat: > > This means anyone extending the base image in their Dockerfile need to > delete the node_modules directory first before they do npm install to > install the exact set of packages and their dependencies that they want. > They would this for various reasons for example they went over all the > dependency graph not just the top level and made sure there are no > legal/license problems, security CVEs, and maybe some packages for their > own purpose. > > This will increase the image size with a layer that never get use. > > The alternative is that the provider can have a Docker file that doesn’t > extend the openwhisk base image and instead extend the nodejs base image > and use the new from feature from Dockerfile to copy the 2 or 3 files out > of the base openwhisk image. > > Now with my Apache Hat: > You will need to blessed and do legal clearance of the npm packages and > all their dependencies to make sure their are compatible with Apache and > then maintain currency with the versions that for currency and also > security patches. > > I know that nodejs6 includes a bunch of npm packages but I was hoping to > delete nodejs:6 from the repo for this reason before graduation to avoid > any problems when going into graduation. > > PS: Anyone is welcome to use the image ibmfunctions/action-nodejs-v10 for > nodejs:10 in their runtimes.json is fully compatible with any openwhisk > deployment. This is the one I use locally in my Mac with docker-compose > deploy. > > - Carlos Santana > @csantanapr > > > On Feb 16, 2019, at 8:57 AM, Dominic Kim wrote: > > > > +1 on this. > > > > > > Best regards > > Dominic > > > > > > 2019년 2월 16일 (토) 오전 10:53, Rodric Rabbah 님이 작성: > > > >> Hello, > >> > >> A few times in recent weeks and twice this past week there was > discussion > >> on slack about our nodejs8 and nodejs10 images and the lack of packages > in > >> these images. As we move to deprecate nodejs6 with its coming end of > life, > >> this is worth re-considering: should we include some popular images in > the > >> base image? > >> > >> We had previously eschewed packages because the thought was providers > roll > >> their own. But I'm finding that our nodejs6 runtime more convenient for > >> some development because of its built-in packages. > >> > >> So I opened a draft PR (new on GitHub!) to add some packages to our > images > >> here: > >> https://github.com/apache/incubator-openwhisk-runtime-nodejs/pull/111 > >> > >> Feedback welcome and especially appreciated if you aren't a provider > that > >> runs their own images. > >> > >> -r > >> > -- Regards, James Thomas
Re: good first issue tweets
+1 On Thu, 14 Feb 2019 at 15:57, Carlos Santana wrote: > +1 > > - Carlos Santana > @csantanapr > > > On Feb 14, 2019, at 7:21 AM, Rodric Rabbah wrote: > > > > There is a github app https://github.com/rajatjindal/goodfirstissue > which > > can be installed/linked to a repo to monitor issues tagged as good first > > issue, and then tweets out a link to those issues. > > > > Here are some of the tweets: > > https://twitter.com/goodfirstissue > > > > Some users of the app: helm, openfaas, asyncy, and google's go-github > repo. > > > > Thoughts on adding the app it to our openwhisk repos? > > > > -r > -- Regards, James Thomas
Re: outstanding PRs on openwhisk repo
Great work Rodric. On Sat, 9 Feb 2019 at 16:22, Carlos Santana wrote: > Thank you Rodric for cleaning the house !! > > - Carlos Santana > @csantanapr > > > On Feb 9, 2019, at 10:32 AM, Rodric Rabbah wrote: > > > > In preparing for the uber next release and staging, I went through all > the > > open pull requests and have merged all that were ready. There are at the > > moment 25 open PRs remaining, of which another 5 I expect we can merge > and > > are waiting on a committer to hit the green merge button. > > > > Of the remaining PRs, some may be abandoned (I left comments in the PR), > a > > few need some discussion to make a decision (I also left comments in the > > PR), and others require some review work. I may have asked some of you on > > this help for help for which I thank you in advance. I have made sure all > > the PRs have appropriate labels. > > > > If you are able to help with the remaining PRs, please take a look at the > > list here: https://github.com/apache/incubator-openwhisk/pulls. Reviews > > take effort and time and the time you spend is appreciated by > contributors > > and project maintainers alike. > > > > I thank you for your patience if you've been waiting on me specifically > for > > a review. I am hoping that this round of housekeeping will help us all > > regain some velocity on accepting contributions. > > > > -r > -- Regards, James Thomas
Pluggable Trigger Feed Event Provider
Hello Whiskers. On Wednesday's Community Call, I presented my work on building a "pluggable trigger feed event provider". The background for this experiment was needing to build another trigger feed event source without having to replicate all the boilerplate needed for trigger management. Here is the presentation from the call: https://speakerdeck.com/jthomas/apache-openwhisk-pluggable-event-providers Video recording of the call is available on the OpenWhisk YouTube channel: https://www.youtube.com/watch?v=krm7X5YpGy0 Feedback on the call was very positive so I've pushed the code to an external Github repo allowing others to have a look at how it works. This is the repo for the "generic event feed provider". The README contains all the instructions on how to create a plugin and run the provider with a pluggable event source. https://github.com/jthomas/openwhisk-pluggable-event-provider Here's an example event plugin I built for an S3-compatible object store. It polls a bucket endpoints and compares file etags, stored in Redis, to determine any file changes. Triggers are fired with file events. https://github.com/jthomas/openwhisk-s3-trigger-feed As discussed on the call, my next steps were - Make the code public for the community to evaluate. (DONE ✅) - Write a few more plugin providers (RabbitMQ, MQTT) to test it further. - Contribute the code back to Apache to become an official component of the project. All feedback welcome! -- Regards, James Thomas
Re: Bi-Weekly Tech Interchange next Wednesday - add agenda topics here
- I'd like to introduce my "pluggable event provider" I worked on recently On Sat, 2 Feb 2019 at 00:20, Justin Halsall wrote: > Hi, > > Please add to this thread any agenda items you'd like to discuss at the > Tech Interchange call next Wednesday (February 6th). > > Call details: > > Web Meeting: Tech Interchange (bi-weekly): > - Day-Time: Wednesdays, 11AM EST(Eastern US), 5PM CET (Central Europe), > 4PM UTC, 12AM CST (Beijing) > - Zoom: https://zoom.us/my/asfopenwhisk > > Cheers, > > Justin Halsall > > Ps. Carlos I noted down your Incubator Release Checklist! -- Regards, James Thomas
Re: Welcome new Committer Michele Sciabarra
Congratulations! On Mon, 7 Jan 2019 at 17:23, Carlos Santana wrote: > OpenWhiskers, > > Yes! Another new Committer! > > Based on his ongoing and valuable contributions to the project, the > OpenWhisk PPMC has elected Michele Sciabarra as a Committer and he has > accepted the invitation. > > Please join me in welcoming him! > > Regards, > -- Carlos > > -- Regards, James Thomas
Re: Welcome new Committer Rob Allen
Awesome news and well deserved! On Mon, 7 Jan 2019 at 17:28, Justin Halsall wrote: > Thats great news! Congrats Rob! > > Sent from my iPhone > > > On Jan 7, 2019, at 12:22 PM, Carlos Santana > wrote: > > > > OpenWhiskers, > > > > Yes! Another new Committer! > > > > Based on his ongoing and valuable contributions to the project, the > > OpenWhisk PPMC has elected Rob Allen as a Committer and he has > > accepted the invitation. > > > > Please join me in welcoming him! > > > > Regards, > > -- Carlos > > > -- Regards, James Thomas
Re: Invoking actions via websockets
Re-posting from the external issue... This would be an excellent feature of the API Gateway . Websocket support is something developers ask about a lot... - We would need to define the error handling process when the the triggers are unavailable or rate-limited. How would we signify to a client that a message wasn't delivered? Another (more difficult) thing to consider is how to make it possible for messages to be sent to listening clients outside of responding to an incoming event. If we take one of the most common examples for a websocket application, a chat application, how could we enable this feature? Ideally, an action could call the API Gateway service with a message to pass to one or more clients currently connected to pass messages that arrived from other sources. On Fri, 26 Oct 2018 at 22:58, Carlos Santana wrote: > Hi Matt > > Do you require changes in the controller, invoker, or runtimes for this? > > Or you think first implementation would be all apigateway side holding the > connecting open as a websocket server to the client, as long the client > keeps sending messages/frames, the apigateway calls web actions with a > single connection to one of the edge/controllers with a keep alive. > > > -- Carlos > > On Fri, Oct 26, 2018 at 2:10 PM Matt Hamann > wrote: > > > I just opened an issue[1] in the `apigateway` repo to discuss the > > ability for the gateway to handle websocket connections from a client > > that could invoke a whisk action `onMessage`. > > > > I'd like to get feedback from the community at large as to this > > proposal. Interested in your thoughts, ideas, etc. > > > > [1] https://github.com/apache/incubator-openwhisk-apigateway/issues/325 > > > > -Matt > > matthew.ham...@gmail.com > > > -- Regards, James Thomas
Re: dotnet 2.1 Runtime for OpenWhisk
This will be an excellent addition to the platform - well done Shawn. I've had lots of people ask me about this in the past! On Wed, 10 Oct 2018 at 21:31, Carlos Santana wrote: > Thanks Alex looking forward for your help > > You can give what Shawn has in the README > > > -- Carlos > > > On Wed, Oct 10, 2018 at 3:51 PM Alex Hitchins > wrote: > > > Hi, I have a good amount of .net experience but not so much with > > openwhisk, although I am interested in the project. If anyone has an > idiots > > guide to it I’ll give it a go! > > > > > On 10 Oct 2018, at 20:40, Carlos Santana wrote: > > > > > > +1 > > > Shawn this is awesome and great demo today > > > > > > I will create a github repo for the runtime, and then you can submit a > PR > > > to it. > > > > > > You already have an ICLA so should be ready to go. > > > > > > If other contributors have background in .NET programming please let us > > > know, it would be good for other to try it out and give feedback > > > > > > -- Carlos > > > > > > > > > On Wed, Oct 10, 2018 at 1:55 PM Shawn Black > > > > wrote: > > > > > >> Howdy, all! > > >> I would like to contribute the code for the .NET 2.1 runtime that I > had > > >> demoed earlier today during the 2018-10-10 Apache OpenWhisk Tech > > >> Interchange meeting. > > >> The current GitHub repo is: > > >> https://github.com/shawnallen85/openwhisk-runtime-dotnet > > >> Thanks!!Shawn > > > > > -- Regards, James Thomas
Re: OpenWhisk officially first-time released all the 12 modules under Apache as incubator project.
Excellent work on this Vincent. On Wed, 26 Sep 2018 at 02:09, Vincent S Hou wrote: > Hi OpenWhiskers, > > After everybody's great effort, OpenWhisk has now successfully releases > all the 12 designated modules: > OpenWhisk > CLI > Catalog > Wskdeploy > Apigateway > Client Go library > Runtime Nodejs > Runtime Java > Runtime Docker > Runtime Swift > Runtime Python > Runtime PHP > > under Apache as incubator project. Thank everyone for the great work. > > All the download links are available at the official website of openwhisk: > http://openwhisk.incubator.apache.org/downloads.html > Some runtime links may return 404, since the Apache mirror is > synchronizing. Eventually all the links will be update-to-date. > > 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: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk 1.12.0-incubating: OpenWhisk python, php and and swift runtimes[RC1]
> > 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: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk 1.12.0-incubating: OpenWhisk nodejs, java and and docker runtimes[RC1]
hank you very much. > > 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: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk 1.12.0-incubating: OpenWhisk python, php and and swift runtimes[RC1]
e correct for each OpenWhisk repo. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > Thank you very much. > > > 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: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -- Regards, James Thomas
Re: AI Actions as a first-class citizen in OpenWhisk
Dragos, Great wiki page! Since I've been playing with TensorFlow.js on OpenWhisk, I definitely think there's a sweet spot for running certain ML tasks using serverless platforms. The suggestions in the wiki page all make sense to me. Access to the GPU is one of the biggest barriers to using more complex models and operations (and even training longer-term). Nvida does have a Docker version that allows you to pass through GPUs ( https://github.com/NVIDIA/nvidia-docker). Another issue I found was the performance difference between warm and cold activations when using customised run images. This could have been resolved it either there was a pre-warmed Node.js image with TF-JS libraries or we have a mechanism to create action packages larger than 48MB. This might include creating actions from packages at an external HTTP address or object storage URI. On 13 August 2018 at 22:17, Dragos Dascalita Haut wrote: > Once you've experienced FaaS, you don't wanna go back. This has been my > experience with AI and FaaS. > > > In particular, running AI inferences in FaaS proved to be a great match: > > - Each function processes one request at a time. A model usually takes 1 > data input and produces 1 data output. > > - Enough code to fit into a function. An AI action loads a model, runs the > inference, and returns the result. > > - In addition, FaaS provides a model to scale to 0 and scale to millions > with the traffic. > > > With OpenWhisk I think we're very close to make AI Actions a first-class > citizen for developers, and I've created a wiki to explore what it would > take to get there [1]. Coincidently James Thomas also published today his > experience with Tensorflow and OpenWhisk [2] > > > I'm interested in your thoughts, and see if there's enough interest in our > community to make this a reality. > > > Feel free to contribute to the wiki with edits, comments, anything you'd > wanna add. > > > [1] - https://cwiki.apache.org/confluence/display/OPENWHISK/AI+Actions > > [2] - https://medium.com/openwhisk/serverless-machine-learning- > with-tensorflow-js-4aa24494a9b4 > > > Thanks, > > dragos > -- Regards, James Thomas
Re: MiniWhisk: what you think?
Michele, I'd also started a project this month called "miniwsk" around local development - great minds! :) I had a similar idea about an instance of the platform that would spin up containers locally. My approach was to implement the OpenWhisk platform API using a stub server that would execute the actions using Docker in the host system. I also wanted to use Go lang for the mock server so that it would be a simple binary I could start on demand. Implementing the API means I can just use all the normal OpenWhisk tools without modification by pointing them to localhost. It's still in the super-early stages of development so I'm not sure when I'll have it ready for publishing... I wasn't going to handle re-build go based stuff as your idea does. It was purely a stub server to invoke containers on demand. On 25 July 2018 at 15:56, Michele Sciabarra wrote: > Hello, in the process of developing some examples for the goproxy, I > realized I want a tool to make easier developing go actions locally. While > it is generally acceptable to deploy your actions straight to the IBM Cloud > for example when you code in Javascript (or Python) it is less desiderable > for Go because compilation time in the cloud is not so fast as it is when > compiled locally, and you have the additional time of uploading a binary > that is generally bigger than javascript actions. > > SO I ended up with this idea of the "miniwhisk". I am posting here to see > if it is acceptable or... there are better solutions. > > My idea of the miniwhisk is a "single action " executor. It should work > more or less this way: > > $ miniwhisk /path/of/action -runtime openwhisk/actionloop-go-v1.10:master > -watch *.go -build make -action demo > > This command will launch the runtime "openwhisk/actionloop-go-v1.10:master" > using docker run, then will watch the files specified with "-w". When a > file changes, it will execute the build command (-build) and then execute > and "init" of the action runtime, post the action to the runtime as an init. > > Additional (and most importantly) it starts a webserver that will listen > to /path/of/action for GET and POST and will then translate requests in > appropriate /run posts for the runtime. > > Basically it is a tool to develop an action in go locally simulating what > would happen when run in the real OpenWhisk. > > > How does sound the idea? Is it worth the effort? > > > > > > > > -- > Michele Sciabarra > openwh...@sciabarra.com > -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating rc2: main OpenWhisk module
I also vote +1 to release OpenWhisk 0.9.0-incubating rc2 module. Checklist for reference: [ X ] Download links are valid. (Please disregard the md5 link, since we do not need it) [ 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 repo. [ X ] All files have license headers if necessary. [ X ] No compiled archives bundled in source archive. On 9 July 2018 at 16:37, Justin Halsall wrote: > Hello everyone, > > I also vote +1 to release OpenWhisk 0.9.0-incubating rc2 module. > > Checklist for reference: > [ X ] Download links are valid. (Please disregard the md5 link, since we > do not need it) > [ 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 repo. > [ X ] All files have license headers if necessary. > [ X ] No compiled archives bundled in source archive. > > Cheers, > Justin Halsall -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module
+1 on this release. Checklist for reference: [X] Download links are valid. [0] Checksums and PGP signatures are valid. (did not verify on this point iteration) [X] Source code artifacts have correct names matching the current release. [X ] LICENSE and NOTICE files are correct for each OpenWhisk repo. [X] All files have license headers if necessary. [X ] No compiled archives bundled in source archive. On 28 June 2018 at 09:03, Bertrand Delacretaz wrote: > Hi, > > On Thu, Jun 28, 2018 at 9:22 AM Markus Thoemmes > wrote: > ... > > - [✓] No compiled archives bundled in source archive. (Other than > gradlew.jar) > > > Is there a procedure to verify the last point? I quickly did a find for > jar files and a find for executable files... > > I also use find + file to look for binaries, something like > > find . -type f | xargs -n10 file | grep -v ASCII > > -Bertrand > -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating
+1 Release as Apache OpenWhisk 0.9.0-incubating. Good work on this everyone. Time to get the ready On 21 June 2018 at 17:35, Priti Desai wrote: > +1 for the release, its been a lot of hard work from the team, great job > Matt, Vincent, and Daisy! > > Cheers > Priti > > -- Regards, James Thomas
Re: [Release] Preparing the release of OpenWhisk
Can we also write up the release process in markdown and store in in the repo to help future release managers (unless Vincent wants to do it forever :))? On 20 June 2018 at 20:59, Vincent S Hou wrote: > Give me the honor to the initiative as the first release manager of > OpenWhisk. > The first version is named after "0.9.0-incubating", based on the semantic > version 2.0. > I am preparing the email for VOTE now. I will send out the email by the > end of today. > > > > 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: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -"Matt Rutkowski" wrote: - > To: dev@openwhisk.apache.org > From: "Matt Rutkowski" > Date: 06/20/2018 03:05PM > Subject: Re: [Release] Preparing the release of OpenWhisk > > Agree, Vincent should be first Release Manager. Do we have a champagne > bottle somewhere? > > Kind regards, > Matt > > > > From: Carlos Santana > To: dev@openwhisk.apache.org > Date: 06/20/2018 01:36 PM > Subject:Re: [Release] Preparing the release of OpenWhisk > > > > Vincent, > > If it's not already clear :-), I think should do the honors, and be > release > manager for the first release :-) > I'm out most of the month of July (vacation). But will volunteer to do a > release in August > > Thread to dev list for vote should have the following Subject "[VOTE] > Release Apache OpenWhisk (incubating) version 0.9.0" > And include the details of the location of the RC, and the instructions > for > voting including the deadline of 72 hours. > > Release Candidate 1 should be located in > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/0.9.0/RC1/ > > It's a requirement that artifacts need to include the string "incubating" > as part of the version. > Since we are trying to use semantic versioning "incubating" should be at > the end. > > dev/incubator/openwhisk/0.9.0/RC1/openwhisk-0.9.0-incubating.tar.gz > dev/incubator/openwhisk/0.9.0/RC1/openwhisk-apigateway-0.9. > 0-incubating.tar.gz > dev/incubator/openwhisk/0.9.0/RC1/openwhisk-cli-0.9.0-incubating.tar.gz > ... > > We should remove "incubator", and put "incubating" at the end. > Also I would remove "sources" from the name. Only sources are distributed > on apache servers. > After graduation, we stop using "-incubating" > > -cs > > On Wed, Jun 20, 2018 at 1:39 PM Vincent S Hou wrote: > > > So far, we can formally name the first version incubator-0.9.0 to > indicate > > the incubator status as well, and use subversion like rc1, rc2, etc, > before > > moving the artifacts to the final release SVN URL. > > > > For incubator-0.9.0-rc1, the package of source code openwhisk in the dev > > SVN URL is named after > openwhisk-apigateway-incubator-0.9.0-sources.tar.gz > > under the folder of apache-openwhisk-incubator-0.9.0-rc1. > > > > Shall we include the name "incubator" as part of the version name? Or it > > does not sound attractive. > > > > > > 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: +1(919)254-7182 <(919)%20254-7182> > > Address: 4205 S Miami Blvd > > < > https://maps.google.com/?q=4205+S+Miami+Blvd=gmail=g > > > > (Cornwallis Drive), Durham, NC 27703, United States > > > > -James Thomas wrote: - > > To: dev@openwhisk.apache.org > > From: James Thomas > > Date: 06/20/2018 01:17PM > > Subject: Re: [Release] Preparing the release of OpenWhisk > > > > 0.9 makes sense to me. > > > > Something to think about it - what would constitute a 1.0 release? > Whilst > > the platform is still evolving rapidly, it has been in production on > > multiple providers for over 12 months. What things would we like to tick > > off before reaching this stage? > > > > On 20 June 2018 at 17:38, Michele Sciabarra > > wrote: > > > > > I agree with 0.9.0 > > > > > > -- > > > Michele Sciabarra > > > openwh...@sciabarra.com > > > > > > On Wed, Jun 20, 2018, at 6:37 PM, Michele Sciabarra wrote: > > > > I agree with 0.9.0. > > > > > > > > -- > > > > Michele Sciabarra > > > > mich...@sciabarra.com > > > > > > > > On Wed, Jun 20, 2018, at 6:31 PM, Rob Allen wrote: > > > > > On 20 Jun 2018, at 16:24, Matt Rutkowski > > wrote: > > > > > > > > > > > > Can we go with 0.9.0? > > > > > > > > > > > > > > > > 0.9.0 is fine with me. > > > > > > > > > > Regards, > > > > > > > > > > Rob > > > > > > > > > > > > > > > > -- > > Regards, > > James Thomas > > > > > > > > > > -- Regards, James Thomas
Re: [Release] Preparing the release of OpenWhisk
0.9 makes sense to me. Something to think about it - what would constitute a 1.0 release? Whilst the platform is still evolving rapidly, it has been in production on multiple providers for over 12 months. What things would we like to tick off before reaching this stage? On 20 June 2018 at 17:38, Michele Sciabarra wrote: > I agree with 0.9.0 > > -- > Michele Sciabarra > openwh...@sciabarra.com > > On Wed, Jun 20, 2018, at 6:37 PM, Michele Sciabarra wrote: > > I agree with 0.9.0. > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > On Wed, Jun 20, 2018, at 6:31 PM, Rob Allen wrote: > > > On 20 Jun 2018, at 16:24, Matt Rutkowski wrote: > > > > > > > > Can we go with 0.9.0? > > > > > > > > > > 0.9.0 is fine with me. > > > > > > Regards, > > > > > > Rob > > > > -- Regards, James Thomas
Re: About Ruby2.5 runtime support proposal(in relation to #3725)
This looks excellent - I've seen lots of people asking about Ruby support
before!
If you had time to write up generic instructions for creating a new
runtime, based on your experiences, it would help others add more. It has
been something we've been meaning to do since the PHP runtime.
Also, if you get time, adding a simple OpenWhisk Ruby client library to the
default runtime would be really useful from a "developer" experience POV.
Just making it easy for developers to invoke functions & triggers from the
runtime would be 80% of the methods needed.
Thanks for the contribution - looking forward to promoting this!
On 6 June 2018 at 10:39, Kei Sawada wrote:
> Hi,
>
> This email is follow-up from #3725 which proposes Ruby2.5 runtime addition.
> https://github.com/apache/incubator-openwhisk/pull/3725
>
> > (perhaps including a small example on how to try it)
> Here is a quick introduction on how to use and test this runtime. Excuse me
> in advance for a little bit awkward installation step, I guess there would
> be better way to do this with fewer steps.
>
> ```
> # 1. Setting up both openwhisk and openwhisk-runtime-ruby
> git clone https://github.com/remore/incubator-openwhisk.git
> cd incubator-openwhisk
> git checkout origin/add-ruby-as-a-kind
> cd tools/vagrant
> ./hello # fail here because pulling image from openwhisk/action-ruby-v2.5
> is not possible yet
> vagrant ssh
> git clone https://github.com/remore/openwhisk-runtime-ruby.git
> cd openwhisk-runtime-ruby/core/ruby2.5Action/
> docker build -t action-ruby-v2.5 -t whisk/action-ruby-v2.5
> openwhisk/action-ruby-v2.5 .
> exit # go back to the host machine
> vagrant provision # resume installation
>
> # 2. Creating a ruby action
> vagrant ssh
> cd openwhisk-runtime-ruby
> echo -e "def main(param)\n {result: param}\nend" > my_action.rb
> wsk action update myAction my_action.rb --docker whisk/action-ruby-v2.5
> ./gradlew core:ruby2.5Action:distDocker
>
> # 3. Try it out
> wsk action invoke myAction --result -p message hello
>
> # 4. Test it
> cd ../openwhisk && ./gradlew install && cd ../openwhisk-runtime-ruby
> ./gradlew :tests:test --tests *actionContainers.
> Ruby25ActionContainerTests*
> ```
>
> Best,
> Kei
>
--
Regards,
James Thomas
Re: Please review our project's draft Apache Incubator June board report
LGTM - nice work Matt. On the "Community" section? Would it be worth adding the growth of the Slack community? We're ~800 members and it is really active. On 5 June 2018 at 18:51, Matt Rutkowski wrote: > Whiskers, > > I have drafted our project board report for this quarter (June); I plan to > post it tomorrow to the board's Wiki; please review and comment here or on > our CWiki: > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85475755 > > Thanks, > Matt > > PS message me if you need CWiki access > -- Regards, James Thomas
Re: Supporting user-configurable warm action containers?
Speaking to external developers about this, people seem happy to pay for this feature. On 31 May 2018 at 12:34, Nick Mitchell wrote: > for nodejs at least: the cost of a few requires of common packages can > easily get you up to the 150-200ms range (e.g. request is a big hitter; and > this is all on top of the cost of starting a container!). perhaps, for > nodejs at least, there are only a few options, ultimately: user pays more > for idle resources; provider pays more for idle stem cells; or users take a > very hard line on the modules they import. > > switching to other (compiled) runtimes might help, e.g. with the recent > work on precompiled go and swift actions? we'd still be left with the > container start times, but at least this is something we can control, e.g. > by requiring users to pay more for access to a larger prewarmed pool? > > nick > > > On Thu, May 31, 2018 at 7:22 AM, James Thomas > wrote: > > > One of most frequent complaints[1][2][3] I hear from developers using > > serverless platforms is coping with cold-start latency when dealing with > > sudden bursts of traffic. > > > > Developers often ask for a feature where they can set the number of warm > > containers kept in the cache for a function. This would allow them to > keep > > a higher number of warm containers for applications with bursty traffic > > and/or upgrade the cached number prior to an anticpated burst of traffic > > arriving. This would be exposed by the managed platforms as a chargable > > feature. > > > > Is this something we could support on OpenWhisk? Ignoring the complexity > > and feasibility of any solution, from a developer POV I can image having > an > > action annotation `max-warm` which would set the maximum number of warm > > containers allowed in the cache. > > > > Tyson is currently working on concurrent activation processing, which is > > one approach to reducing cold-start delays[4]. However, there are some > > downsides to concurrent activations, like no runtime isolation for > request > > processing, which might make this feature inappropraite for some users. > > > > [1] > > https://www.reddit.com/r/aws/comments/6w1hip/how_many_ > > successive_lambda_invocations_will_use_a/ > > [2] > > https://twitter.com/search?f=tweets=default=%20% > > 23AWSWishlist%20warm=typd > > [3] > > https://theburningmonk.com/2018/01/im-afraid-youre- > > thinking-about-aws-lambda-cold-starts-all-wrong/ > > [4] - https://github.com/apache/incubator-openwhisk/pull/2795 > > > > -- > > Regards, > > James Thomas > > > -- Regards, James Thomas
Supporting user-configurable warm action containers?
One of most frequent complaints[1][2][3] I hear from developers using serverless platforms is coping with cold-start latency when dealing with sudden bursts of traffic. Developers often ask for a feature where they can set the number of warm containers kept in the cache for a function. This would allow them to keep a higher number of warm containers for applications with bursty traffic and/or upgrade the cached number prior to an anticpated burst of traffic arriving. This would be exposed by the managed platforms as a chargable feature. Is this something we could support on OpenWhisk? Ignoring the complexity and feasibility of any solution, from a developer POV I can image having an action annotation `max-warm` which would set the maximum number of warm containers allowed in the cache. Tyson is currently working on concurrent activation processing, which is one approach to reducing cold-start delays[4]. However, there are some downsides to concurrent activations, like no runtime isolation for request processing, which might make this feature inappropraite for some users. [1] https://www.reddit.com/r/aws/comments/6w1hip/how_many_successive_lambda_invocations_will_use_a/ [2] https://twitter.com/search?f=tweets=default=%20%23AWSWishlist%20warm=typd [3] https://theburningmonk.com/2018/01/im-afraid-youre-thinking-about-aws-lambda-cold-starts-all-wrong/ [4] - https://github.com/apache/incubator-openwhisk/pull/2795 -- Regards, James Thomas
Re: Today's Tech Interchange meeting video and notes posted
Thanks to Chetan, apologies again for the short notice! On 11 April 2018 at 17:50, Matt Rutkowski <mrutkow...@apache.org> wrote: > Thanks Chetan for being an excellent host and stepping up in place of > James so quickly. > > Youtube: https://youtu.be/FwuPqleveCA > CWiki: https://cwiki.apache.org/confluence/display/OPENWHISK/ > 2018-04-11+OW+Tech+Interchange+-+Meeting+Notes > > Will verify James when back in health can host on the 25th > > cheers, > -mr > -- Regards, James Thomas
Re: any updates to include in OW quarterly board report draft?
Thanks again for taking on this Matt! On 5 March 2018 at 22:02, Carlos Santana <csantan...@gmail.com> wrote: > Thanks Matt for handling this +1 > > - Carlos Santana > @csantanapr > > > On Mar 5, 2018, at 12:20 PM, Matt Rutkowski <mrutk...@us.ibm.com> wrote: > > > > working in earnest to draft our project's quarterly board report on our > > CWIKI: > > https://cwiki.apache.org/confluence/display/OPENWHISK/2018-03+March > > > > Please feel free to send me of notable items/features/contribs. you do > not > > want me to miss (as I will use primarily the "dev" list discussions, as > > well as scan the merged PRs over last 3 months across most repos. > > > > Any help appreciated. > > > > Kind regards, > > Matt > > > > > -- Regards, James Thomas
Re: Getting Started for those in a hurry.
Hello Alex! If you want to run the platform locally, we have a number of options including using Docker Compose ( https://github.com/apache/incubator-openwhisk-devtools/tree/master/docker-compose), running a VM using Vagrant ( https://github.com/apache/incubator-openwhisk#quick-start) or even Kubernetes (https://github.com/apache/incubator-openwhisk-deploy-kube). Docker Compose is probably the simplest and fastest if you just want to play around, I wrote up an overview of this approach here recently ( http://jamesthom.as/blog/2018/01/19/starting-openwhisk-in-sixty-seconds/). If you just want to try OpenWhisk out, you can always sign up for a free IBM Cloud Functions account which is a managed OpenWhisk platform with a free tier in the public cloud. Adding a C# runtime is something people have talked about for a while but no-one has done much with yet... There is an open isse about this: https://github.com/apache/incubator-openwhisk/issues/3003 If you can compile the c# source code into a static binary (compiled for the linux architecture), you can deploy this as a native function without any changes to the platform. If you do need to provide the runtime as a native runtime, you will need to implement the simple HTTP API exposed by the runtime containers that the platform talks to. Another community member recently added PHP support, so his PR would be a good place to start for instructions. https://github.com/apache/incubator-openwhisk/pull/2415 All the runtimes are now in separate projects in Github. Reviewing the existing runtimes should give you a good place to start. Feel free to ask questions on here or on the Slack channel. https://github.com/search?utf8=%E2%9C%93=incubator-openwhisk-runtime= On 22 February 2018 at 10:05, Alex Hitchins <a...@alexhitchins.com> wrote: > Hello all, > > I'm quite interested in the project, can anyone point me to some resources > to get me going quickly? > > I come from a long C# background and am quite interested in adding this > tooling (or .Net Core) to the mix of technologies already available. > > > Alexander Hitchins > > E: a...@alexhitchins.com > W: alexhitchins.com > M: 07788 423 969 > T: 01892 523 587 > > > -- Regards, James Thomas
Re: Benchmarking the Go server: results of performance comparison against the Dockerskeleton
Michele, Impressive results! Looking forward to seeing this develop. On 17 February 2018 at 14:21, Michele Sciabarra <openwh...@sciabarra.com> wrote: > Hello, Whiskers! > > Before starting to implement the support with pipes, I run some benchmarks. > I wanted to be sure I were not wasting time doing something useless. > > Well, I was rewarded by numbers much better than I expected. > Without any further ado here there are the results: > > | Label | # Samples | Average | Median | 90% Line | 95% Line | 99% > Line | Min | Max | > |---|---|-||--|- > -|--|-|--| > | Python+System | 1 | 673 |686 | 766 | 797 | > 853 | 10 | 1180 | > | GoServer | 1 | 2 | 2 |3 |6 | >15 | 1 | 78 | > > > The test is just ONE, with 100 threads running 100 requests. However the > numbers are pretty eloquent. > > Basically, on average a request to the Go server took 2 milliseconds, > against an average of 673 ms for the docker support. > Also 90% of requests in Go took less that 3 ms, against 766ms with the > system call. > > No surprise here no one uses CGI anymore since a long time! > > --- > > Also the size of the images is significant: > > | sciabarracom/openwhisk-hello latest 43425039e0902 > hours ago 16.7MB | > | sciabarracom/openwhisk-execlatest ba516ca87a682 > hours ago 10.4MB | > | openwhisk/dockerskeleton latest 25d1878c2f314 > months ago109MB | > | openwhisk/python3actionlatest e7346758b2014 > months ago289MB | > > (the `openwhisk-image` is the image with the proxy and the action, while > the `openwhisk-exec` contains just the proxy) > > --- > > All the instructions how to run the benchmark by yourself are in the repo > here: > > https://github.com/sciabarracom/openwhisk-runtime-go > > -- > Michele Sciabarra > openwh...@sciabarra.com > -- Regards, James Thomas
Re: Generalising the proposed approach for Go actions to support Generic Binary Actions.
Great proposal, looks like a really good solution to the challenges discussed. Looking foward to seeing this in action. On 15 February 2018 at 20:20, Michele Sciabarra <openwh...@sciabarra.com> wrote: > I spent some time thinking about my proposal to support Go Actions, and I > tried to address some weaknesses that emerged in the discussion (again, thank > to James Thomas for pointing them out). > > First, the most relevant, my approach requires you implement a supporting > library able to run an http server in each language you want to support. So > one for Swift, one for C/C++ (why not?), even one for Rust or D or Haskell or > whatever. While it is relatively simple, it is definitely not a generic > solution for supporting binaries. > > Second, there are some secondary problems: a “race condition”, when I upload > an action, the current server will be closed so it won’t serve actions. For > a very small amount of time, but it happens. Also I have some concerns about > what happens if the user does not upload a proper executable. It could break > the runtime, so some validation is needed. > > I hence decided to raise the bar and think to a better implementation. My > updated proposal is now an extension of the current implementation, but using > a pipe and keeping the "child" process running to serve actions, not > terminate and be started again at each request. > > Instead of “exec” we should launch a process and pipe input, output and > error. The process however should not be expected (as it is now in Docker > actions) to read the standard input, write some logs then a serialised json > objects and then terminate. > > Instead, the uploaded binary should be expected to: > > * read continuously the standard input line by line > * interpret a single line as a serialised json object > * write logs IN THE STANDARD ERROR > * write the answer in the output as a single line > > In this way we can basically use all the compiled languages using just the > standard libraries. It will behaves like a standard command line function. > Well, almost (it still will have to encode and decode json). > > A controlling process (of course done in Go) will receive a “/run” request , > then it will feed to the process, read his answer and then return the answer. > > The implementation is basically an extension of what I already coded in Go > (no code to throw away). It is just a bit more difficult... > > How does this updated proposal sound like? > > -- > Michele Sciabarra > openwh...@sciabarra.com -- Regards, James Thomas
Re: First Implementation of the self-replacing Go support for OpenWhisk
Michele,
Great work on getting an implemention working so quickly... I've been
playing with it locally and it works perfectly. I have a couple of
questions about the error handling and exec process.
1. Notifying user when exec fails?
Looking at the code, the exec to replace the binary happens after the
`/init` HTTP response is returned. (I assume this is because the
socket would be closed otherwise?)
https://github.com/sciabarracom/openwhisk-runtime-go/blob/master/openwhisk/initHandler.go#L71
If the exec fails, the library logs out a mesage to the console but
this won't be available to the end user IIRC. I think it's important
to surface this error to the user. One of the main issues people face
with serverless is the pain in debugging.
If someone compiles the binary for the wrong platform or makes another
mistake building the deployment archive, it will fail silently and
then return the default response on run. Could we store this error
message internally and return in the default `run` response if that
happens?
2. Can you explain how the HTTP socket is managed when replacing the
binary? Does it get automatically closed and then re-opened by the new
process? I can't find enough information in the exec man page to help
me understand what happens in this instance.
2.1 If the socket does get closed and re-opened, they will be a tiny
amount of time when the HTTP server is not available. It'd be good to
hear from someone with more experience in the platform that there's no
way this race condition could be triggered, i.e. a `/run` request is
fired before HTTP service is available again.
I'm looking forward to trying out this binary runtime with other languages!
On 13 February 2018 at 22:07, Michele Sciabarra <openwh...@sciabarra.com> wrote:
> As promised I released a first implementation of Go support using the
> technique I described before.
>
> In short, a library implementing the proxy and serving both /run and /init,
> with the ability of replace itself with a new version.
>
> Using the library, implementing a function in Go looks like this:
>
> ---
> package main
>
> import (
> "encoding/json"
> "fmt"
>
> "github.com/sciabarracom/openwhisk-runtime-go/openwhisk"
> )
>
> func hello(event json.RawMessage) (json.RawMessage, error) {
> // input and output
> var input struct{ Name string }
> var output struct {
> Greetings string `json:"greetings"`
> }
> // read the input event
> json.Unmarshal(event, )
> if input.Name != "" {
> // handle the event
> output.Greetings = "Hello, " + input.Name
> fmt.Println(output.Greetings)
> return json.Marshal(output)
> }
> return nil, fmt.Errorf("no name specified")
> }
>
> func main() {
> openwhisk.Start(ciao)
> }
> ---
>
> Actually in practice it is better to place the function in a separate package
> for implementing some tests, because apparently adding tests in the main
> package does not work.
>
> Source code of the library is here:
>
> https://github.com/sciabarracom/openwhisk-runtime-go
>
> Here is a simple transcription of how it works and how I tested it.
>
> First you build a couple of executable, and for simplicity you also prepare
> the json payload for the init.
>
> $ cd test
> $ go build -o hello ../main/hello.go
> $ go build -o ciao ../main/ciao.go
> $ echo '{"value":{"binary":true,"code":"'$(base64 hello)'"}}' >hello.json
> $ echo '{"value":{"binary":true,"code":"'$(base64 ciao)'"}}' >ciao.json
>
> Now you can start the actual server
>
> $ go run ../main/exec.go
>
> Now the magic happens.
>
> Default behaviour (no executable)
>
> ```
> $ curl -XPOST http://localhost:8080/run -d '{"value":{"name":"Mike"}}'
> {"error":"the action failed to locate a binary"}
> ```
>
> Now post the `hello` handler and run it:
>
> ```
> $ curl -XPOST http://localhost:8080/init -d @hello.json
> OK
> $ curl -XPOST http://localhost:8080/run -d '{"value":{"name":"Mike"}}'
> {"greetings":"Hello, Mike"}
> ```
>
> As you can see, the function changed and now it implements the "hello"
> handler.
>
> But the replaced server is still able to run init so let's do it again,
> replacing with the "ciao" handler.
>
>
> ```
> $ curl -XPOST http://localhost:8080/init -d @ciao.json
> OK
> $ curl -XPOST http://localhost:8080/run -d '{"value&qu
