Re: New OpenWhisk PMC Members: Brendan Doyle and Cosmin Stanciu
Welcome and congratulations Brendan and Cosmin! Kind regards, Matt
Re: [VOTE] Release Apache OpenWhisk Client Js (v3.21.5, rc1)
+1 for the release of openwhisk-client-js 3.21.5 rc1 -Matt Verified locally: $ ./rcverify.sh openwhisk-client-js 3.21.5 rc1 rcverify.sh (script SHA1: 7FC5 5DBE 1809 6D92 DEFF 0E31 D138 059B 8F27 20F7) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.Mgdl0xz4 fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-client-js-3.21.5-sources.tar.gz... ok fetching openwhisk-client-js-3.21.5-sources.tar.gz.asc... ok fetching openwhisk-client-js-3.21.5-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (new keys imported (processed 13 unchanged 11)) gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) " not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: key B1457C3D7101CC78: "James Thomas " not changed gpg: key A600E3331427515D: "Olivier Tardieu " not changed gpg: key 804F627B2D1BD1A0: 6 signatures not checked due to missing keys gpg: key 804F627B2D1BD1A0: "Alexander Klimetschek (Adobe Work Email) " not changed gpg: key 758C332F8D30E5A2: 1 signature not checked due to a missing key gpg: key 758C332F8D30E5A2: "Alexander Klimetschek (Apache Committer Key) " not changed gpg: key B5B8ADA933BB2FFF: "Dominic Kim " not changed gpg: key A1F071AF3F62EEFF: 3 signatures not checked due to missing keys gpg: key A1F071AF3F62EEFF: "keybase.io/akrabat " not changed gpg: key 395282A61D88D0AC: "Matt Rutkowski " not changed gpg: key 7050DAD4D8D21A6B: "Shawn Black " not changed gpg: key 1683F2D3AF54F2F1: public key "Tyson Norris " imported gpg: key 44FA19E603F812E5: public key "Cosmin Stanciu (CODE SIGNING KEY) " imported gpg: Total number processed: 13 gpg: imported: 2 gpg: unchanged: 11 unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-client-js-3.21.5-sources.tar.gz... ok openwhisk-client-js-3.21.5-sources.tar.gz: 06B7D8FB 6F5DC5CC A3BDFB08 6952FD10 8478EC3D 3A16B2C9 200D0157 0A3D2548 01DD9030 6FDDA0E7 EEF39D8E 594504AD 069AFD40 C85F3F09 CB5E4809 153F6D2B validating sha512... passed verifying asc... passed (signed-by: Cosmin Stanciu (CODE SIGNING KEY) ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed scanning package-lock.json for version match... passed removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.Mgdl0xz4)... ok
Re: openwhisk-runtime-ballerina -- time to archive repository?
+1 to archive. I do not know of any active maintainers nor any provider using this runtime. On 2021/09/24 14:05:19, "David P Grove" wrote: > > Is there any interest in maintaining this runtime? It's based on a fairly > old version of ballerina (0.990.2), the build has been broken for months, > and we've never made a release. > > My inclination would be to archive the repository unless there is someone > who is willing to maintain it. > > --dave >
Re: [VOTE] Release Apache OpenWhisk Catalog (v1.0.0, rc1)
+1 to the release of openwhisk-catalog-1.0.0 rc1 -MR rcverify.sh (script SHA1: A042 C31A 38AF 8EBB F150 0819 A448 DE52 BFE1 258F) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.P30NXt7i fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-catalog-1.0.0-sources.tar.gz... ok fetching openwhisk-catalog-1.0.0-sources.tar.gz.asc... ok fetching openwhisk-catalog-1.0.0-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (keys already imported (processed 11 unchanged 11)) unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-catalog-1.0.0-sources.tar.gz... ok openwhisk-catalog-1.0.0-sources.tar.gz: C242F1C1 95D584F1 0C88AEA4 97E759E1 29F01748 1434824B A23BAE24 60C971C1 E3A80C43 2362DA8C DFF3050A A933645A 3B765649 7772357A 553812C5 E0CDB59A validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed (none detected) scanning package-lock.json for version match... passed (none detected) removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.P30NXt7i)... ok
Re: [VOTE] Release Apache OpenWhisk VSCode Extension (v1.1.0, rc1)
On 2021/06/04 09:38:01, Dominic Kim wrote: > Thank you, Kent for the changes. > > And I suppose we can still proceed with the release without any restart as > `.asf.yaml` file is not included in the release. > > -dom Hi Dom, Actually, the referenced PR also changes the README... that means that you would have to determine if those changes warranted an RC2 or if it gets picked up after an RC1 release. -MR
Re: [Discuss] Release the first IDE plugins.
Completely support such a release and agree with Rodric... Awesome! -MR
Re: [VOTE] Release Apache OpenWhisk Client Js (v3.21.4, rc1)
+1 to release Apache OpenWhisk Client Js (v3.21.4, rc1). My rcverify results are below. [x] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Matt tmp $ ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.21.4 rc1 rcverify.sh rcverify.sh (script SHA1: 4287 FB51 CAAF A0F8 EFFE 956A E004 9F9D 0DBD E46D) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.JrBEnLPs fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-client-js-3.21.4-sources.tar.gz... ok fetching openwhisk-client-js-3.21.4-sources.tar.gz.asc... ok fetching openwhisk-client-js-3.21.4-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (new keys imported (processed 11 unchanged 10)) gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) " not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: key B1457C3D7101CC78: "James Thomas " not changed gpg: key A600E3331427515D: "Olivier Tardieu " not changed gpg: key 804F627B2D1BD1A0: 6 signatures not checked due to missing keys gpg: key 804F627B2D1BD1A0: "Alexander Klimetschek (Adobe Work Email) " not changed gpg: key 758C332F8D30E5A2: 1 signature not checked due to a missing key gpg: key 758C332F8D30E5A2: "Alexander Klimetschek (Apache Committer Key) " not changed gpg: key B5B8ADA933BB2FFF: "Dominic Kim " not changed gpg: key A1F071AF3F62EEFF: 3 signatures not checked due to missing keys gpg: key A1F071AF3F62EEFF: "keybase.io/akrabat " not changed gpg: key 395282A61D88D0AC: "Matt Rutkowski " not changed gpg: key 7050DAD4D8D21A6B: public key "Shawn Black " imported gpg: Total number processed: 11 gpg: imported: 1 gpg: unchanged: 10 unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-client-js-3.21.4-sources.tar.gz... ok openwhisk-client-js-3.21.4-sources.tar.gz: D3DBDCB6 DA99FA56 9AA9ADD8 4B662191 ECBFE472 4CBFF128 69F96915 02DA48F9 440009D8 61EE6257 198BEC59 D90BEE49 33FF43EC 7ABCC871 ECA94D7E B5B8D7AC validating sha512... passed verifying asc... passed (signed-by: Rodric Rabbah ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed scanning package-lock.json for version match... passed removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.JrBEnLPs)... ok On 2021/05/03 02:24:56, Dominic Kim wrote: > Hi. > > +1 to release Apache OpenWhisk Client Js (v3.21.4, rc1) > > The rcverify results are attached below. > > -dom > > > Please vote to approve this release: > > [x] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [x] Download links are valid. > [x] Checksums and PGP signatures are valid. > [x] Source code artifacts have correct names matching the current release. > [x] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [x] All files have license headers as specified by OpenWhisk project > policy [1]. > [x] No compiled archives bundled in source archive. > > --- > $ ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.21.4 rc1 > rcverify.sh (script SHA1: 4287 FB51 CAAF A0F8 EFFE 956A E004 9F9D 0DBD > E46D) > working in the following directory: > /var/folders/jc/wfhtkrln4q7cz9pxz24rbkdmgp/T/tmp.4KilHOWN > fetching tarball and signatures from > https://dist.apache.org/repos/dist/dev/openwhisk/rc1 > fetching openwhisk-client-js-3.21.4-sources.tar.gz... ok > fetching openwhisk-client-js-3.21.4-sources.tar.gz.asc... ok > fetching openwhisk-client-js-3.21.4-sources.tar.gz.sha512... ok > fetching apache license... ok > fetching release keys... ok > importing keys... ok (new keys imported (processed 11 unchanged 10)) > gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) < > houshen...@apache.org>" not changed > gpg: key 22907064147F886E: "Dave Grove " not changed > gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed > gpg: key B1457C3D7101CC78: "James Thomas " not > changed > gpg: key A600E3331427515D: "Olivier Tardieu &qu
Re: [VOTE] Release Apache OpenWhisk Runtime Java, OpenWhisk Runtime Python, OpenWhisk Runtime Ruby (v1.16.0, rc1)
[X] +1 Approve the release of OpenWhisk Runtime Java 1.16.0, Python 1.16.0 and Ruby 1.16.0 - Matt My verifications: $ ./rcverify.sh openwhisk-runtime-java 'OpenWhisk Runtime Java' 1.16.0 rc1 rcverify.sh (script SHA1: 4287 FB51 CAAF A0F8 EFFE 956A E004 9F9D 0DBD E46D) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.CBcUps9D fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-runtime-java-1.16.0-sources.tar.gz... ok fetching openwhisk-runtime-java-1.16.0-sources.tar.gz.asc... ok fetching openwhisk-runtime-java-1.16.0-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (keys already imported (processed 10 unchanged 10)) unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-runtime-java-1.16.0-sources.tar.gz... ok openwhisk-runtime-java-1.16.0-sources.tar.gz: 9BCB479A 0A557A5F C768DF86 2F7A08D1 0BF0B0A2 BDB4E0DA 4477D81C E2F050F1 F1FB5148 946491CE 1B080928 189C892E 56EB6F9A 1C1C1ACD 6D47A8D5 EE6230EF validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed (none detected) scanning package-lock.json for version match... passed (none detected) removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.CBcUps9D)... ok Matt tmp $ ./rcverify.sh openwhisk-runtime-python 'OpenWhisk Runtime Python' 1.16.0 rcverify.sh (script SHA1: 4287 FB51 CAAF A0F8 EFFE 956A E004 9F9D 0DBD E46D) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.VNmx8DxE fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-runtime-python-1.16.0-sources.tar.gz... ok fetching openwhisk-runtime-python-1.16.0-sources.tar.gz.asc... ok fetching openwhisk-runtime-python-1.16.0-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (keys already imported (processed 10 unchanged 10)) unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-runtime-python-1.16.0-sources.tar.gz... ok openwhisk-runtime-python-1.16.0-sources.tar.gz: 2AFF79B5 3351F398 671E448B 6206EFD1 3ADC3169 35A018FD 4B0BD25A E493C590 48FDAA0D FC3676DF 46C72A2E 016B2E28 DB7CDA15 2B5A5132 A72D9A22 2F7672EA validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed (none detected) scanning package-lock.json for version match... passed (none detected) removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.VNmx8DxE)... ok Matt tmp $ ./rcverify.sh openwhisk-runtime-ruby 'OpenWhisk Runtime Ruby' 1.16.0 rc1 rcverify.sh (script SHA1: 4287 FB51 CAAF A0F8 EFFE 956A E004 9F9D 0DBD E46D) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.xmdzAusE fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-runtime-ruby-1.16.0-sources.tar.gz... ok fetching openwhisk-runtime-ruby-1.16.0-sources.tar.gz.asc... ok fetching openwhisk-runtime-ruby-1.16.0-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (keys already imported (processed 10 unchanged 10)) unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-runtime-ruby-1.16.0-sources.tar.gz... ok openwhisk-runtime-ruby-1.16.0-sources.tar.gz: 544D5F8F 300ACBEB 7BE3DF3A FC1B54B2 4931AA45 45E409D2 CDD1C71D C18B951F 9A13F455 7B2B357E DE220AEB 24E38A86 5D122728 FBCE2D17 D3FE45C2 65ADDB20 validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed (none detected) scanning package-lock.json for version match... passed (none detected) removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.xmdzAusE)... ok
Re: [VOTE] Release Apache OpenWhisk Runtime Rust (v1.2.0, rc1)
+1 to release OpenWhisk Runtime Rust v1.2.0 My verification results: rcverify.sh (script SHA1: 4287 FB51 CAAF A0F8 EFFE 956A E004 9F9D 0DBD E46D) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.9zPG6F5E fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-runtime-rust-1.2.0-sources.tar.gz... ok fetching openwhisk-runtime-rust-1.2.0-sources.tar.gz.asc... ok fetching openwhisk-runtime-rust-1.2.0-sources.tar.gz.sha512... ok fetching apache license... ok fetching release keys... ok importing keys... ok (keys already imported (processed 10 unchanged 10)) unpacking tar ball... ok cloning scancode... ok computing sha512 for openwhisk-runtime-rust-1.2.0-sources.tar.gz... ok openwhisk-runtime-rust-1.2.0-sources.tar.gz: 9EE1BF18 17E0DF37 2523C776 9E20E3CA DA68E0DC 9E45D8D8 581B242F A1CDEACC 432AB5EC 436C51BA 1AF89E91 2D99C79D AE39A6C2 A29721D1 2D99176F DC51C28F validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed scanning package.json for version match... passed (none detected) scanning package-lock.json for version match... passed (none detected) removing the scratch space (/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.9zPG6F5E)... ok -Matt
Re: [DISCUSS] update release of npm client
+1 All for keeping our clients updated and released regularly.
[ANNOUNCE] Apache OpenWhisk Command-line Interface (CLI) version 1.2.0 released
The Apache OpenWhisk project is pleased to announce the release of the Apache OpenWhisk Command-Line Interface (CLI) version 1.2.0. Apache OpenWhisk is an open source, distributed Serverless platform that executes functions (fx) in response to events at any scale. OpenWhisk manages the infrastructure, servers and scaling using Docker containers allowing focus on building amazing and efficient applications. For full details about Apache OpenWhisk, please see https://openwhisk.apache.org Apache OpenWhisk Command-Line Interface (CLI) is a unified tool that provides a consistent interface to interact with OpenWhisk services. The CLI provides developers a means to interact with the OpenWhisk programming model and manage resources such as actions, activations, triggers, rules, packages and APIs. It utilizes the Apache OpenWhisk Go Client for performing RESTful API calls to OpenWhisk platform implementations and incorporates the Apache OpenWhisk Whisk Deploy (wskdeploy) utility for YAML-based manifest deployments. The full change log is available at: https://github.com/apache/openwhisk-cli/releases/tag/1.2.0 Source archives and verification files are available at https://openwhisk.apache.org/downloads.html Regards, Matt Rutkowski
[RESULT][VOTE] Release Apache OpenWhisk Command-line Interface (CLI) (v1.2.0, rc1)
This vote is now closed. The vote was successful with 5 binding +1 votes (Dave, Dragos, Rob Allen, Priti, Matt) and no other votes cast. I will continue with the release process. - Matt
Re: [VOTE] Release Apache OpenWhisk Command-line Interface (CLI) (v1.2.0, rc1)
Formally adding my +1 binding vote to "Approve the release" of the CLI v1.2.0 (note that I ran the rcverify tool as part of the release manager process to confirm conformance). -Matt
[VOTE] Release Apache OpenWhisk Command-line Interface (CLI) (v1.2.0, rc1)
Hi Whiskians, This is a call to vote on releasing version 1.2.0 release candidate rc1 of the following project module with artifacts built from the Git repositories and commit IDs listed below. OpenWhisk Command-line Interface (CLI): 7c47ef1dbad550566114baf976c091b4cdd9e678 Details of the commits can be found here: https://github.com/apache/openwhisk-cli/commit/7c47ef1dbad550566114baf976c091b4cdd9e678 The corresponding candidate release artifacts can be found here: https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-cli-1.2.0-sources.tar.gz https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-cli-1.2.0-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-cli-1.2.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=927cdc6aa2b07fd043bba225b89fbdc0c7e204df Usage: curl -s "https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=927cdc6aa2b07fd043bba225b89fbdc0c7e204df; -o rcverify.sh chmod +x rcverify.sh ./rcverify.sh openwhisk-cli 'OpenWhisk Command-line Interface (CLI)' 1.2.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 Thanks, Matt
[ANNOUNCE] Apache OpenWhisk Whisk Deploy (wskdeploy) v1.2.0 released
The Apache OpenWhisk project is pleased to announce the release of Apache OpenWhisk Whisk Deploy (wskdeploy) version 1.2.0. Apache OpenWhisk is an open source, distributed Serverless platform that executes functions (fx) in response to events at any scale. OpenWhisk manages the infrastructure, servers and scaling using Docker containers allowing focus on building amazing and efficient applications. For full details about Apache OpenWhisk, please see https://openwhisk.apache.org Apache OpenWhisk Whisk Deploy is a utility to help you describe and deploy any part of the OpenWhisk programming model using a YAML manifest file. Use it to deploy all of your OpenWhisk project's Packages, Actions, Triggers, Rules and more using a single command! This version is built using Golang version 1.15, updated to use Go Module for dependency management and supports the most current tagged versions of dependent packages. The full change log is available at https://github.com/apache/openwhisk-wskdeploy/releases/tag/1.2.0 Source archives and verification files are available at https://openwhisk.apache.org/downloads.html Regards, Matt Rutkowski
[RESULT][VOTE] Release Apache OpenWhisk Whisk Deploy (wskdeploy) (v1.2.0, rc1)
This vote is now closed. The vote was successful with 5 binding +1 votes (Dave, Dominic, Rob Allen, Priti, Matt) and no other votes cast. I will continue with the release process. - Matt
Re: [VOTE] Release Apache OpenWhisk Whisk Deploy (wskdeploy) (v1.2.0, rc1)
I wish to append my +1 vote as well... [X] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [X] Download links are valid. [X] Checksums and PGP signatures are valid. [X] Source code artifacts have correct names matching the current release. [X] LICENSE and NOTICE files are correct for each OpenWhisk repository. [X] All files have license headers as specified by OpenWhisk project policy [1]. [X] No compiled archives bundled in source archive. - Matt
[VOTE] Release Apache OpenWhisk Whisk Deploy (wskdeploy) (v1.2.0, rc1)
Hi Whiskers, This is a call to vote on releasing version 1.2.0 release candidate rc1 of the following project module with artifacts built from the Git repositories and commit IDs listed below. OpenWhisk Whisk Deploy (wskdeploy): 03df1126c3b5205d642738479a08bb7cd66a03b3 Details of the commits can be found here: https://github.com/apache/openwhisk-wskdeploy/commit/03df1126c3b5205d642738479a08bb7cd66a03b3 The corresponding candidate release artifacts can be found here: https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-wskdeploy-1.2.0-sources.tar.gz https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-wskdeploy-1.2.0-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-wskdeploy-1.2.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=79084efe2b09712191c89da01ae48c2e660dae74 Usage: curl -s "https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=79084efe2b09712191c89da01ae48c2e660dae74; -o rcverify.sh chmod +x rcverify.sh ./rcverify.sh openwhisk-wskdeploy 'OpenWhisk Wskdeploy' 1.2.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 Thanks, Matt
[ANNOUNCE] Apache OpenWhisk Client Go v1.2.0 released
The Apache OpenWhisk project is pleased to announce the release of Apache OpenWhisk Client Go version 1.2.0. Apache OpenWhisk is an open source, distributed Serverless platform that executes functions (fx) in response to events at any scale. OpenWhisk manages the infrastructure, servers and scaling using Docker containers allowing focus on building amazing and efficient applications. For full details about Apache OpenWhisk, please see https://openwhisk.apache.org Apache OpenWhisk Client Go is a client library to access the RESTful Openwhisk API using Go language (https://golang.org/). This client version is built using Golang version 1.15, updated to use Go Module for dependency management and supports the most current tagged versions of dependent packages. The full change log is available at https://github.com/apache/openwhisk-client-go/releases/tag/1.2.0 Source archives and verification files are available at https://openwhisk.apache.org/downloads.html Regards, Matt Rutkowski
[RESULT][VOTE] Release Apache OpenWhisk Client Go (v1.2.0, rc1)
This vote is now closed. The vote was successful with 5 binding +1 votes (Rodric, Dave, Dominic, Rob Allen, Matt) and no other votes cast. I will continue with the release process. - Matt
Re: [VOTE] Release Apache OpenWhisk Client Go (v1.2.0, rc1)
Would like to add my: +1 Approve the release OpenWhisk Client Go 1.2.0 rc1 Release verification checklist for reference: [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are correct for each OpenWhisk repository. [x] All files have license headers as specified by OpenWhisk project policy [1]. [x] No compiled archives bundled in source archive Checked with rcverify and manual inspection. -- Matt
[VOTE] Release Apache OpenWhisk Client Go (v1.2.0, rc1)
Hi Whiskers, This is a call to vote on releasing version 1.2.0 release candidate rc1 of the following project module with artifacts built from the Git repositories and commit IDs listed below. OpenWhisk Client Go: 87edc23647174648fe52939201ebb276e0899f83 Details of the commits can be found here: https://github.com/apache/openwhisk-client-go/commit/87edc23647174648fe52939201ebb276e0899f83 The corresponding candidate release artifacts can be found here: https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-go-1.2.0-sources.tar.gz https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-go-1.2.0-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-go-1.2.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=3eb051f Usage: curl -s "https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=3eb051f; -o rcverify.sh chmod +x rcverify.sh ./rcverify.sh openwhisk-client-go 'OpenWhisk Client Go' 1.2.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 Thanks, Matt
Re: [DISCUSS] Staged release of "go" client tools
In case anyone wants to preview/test/review what would go into each potential 1.2 release of these repos., you can review these Draft PRs which would prep. the repos if we agree to go ahead: - client-go: https://github.com/apache/openwhisk-client-go/pull/147 - wskdeploy: https://github.com/apache/openwhisk-wskdeploy/pull/1126 - cli: https://github.com/apache/openwhisk-cli/pull/498 Cheers, Matt
[DISCUSS] Staged release of "go" client tools
Hello Whiskers! If you have not seen, I have been trying to pay down technical debt in the Whisk Deploy tool and get it building using Go 1.15, Go Modules and the latest (direct) package dependencies as well as using the latest Gradle. Since "wskdeploy" depends on the Go client as well as is a package used by our OpenWhisk CLI, I have made similar updates to both those repos. as well so all are brought up-to-date using the same versioned tooling/runtime/libs. All docs (READMEs) have been updated to reflect the new, simper way of building and updating the project using "go mod" and how to build for one or more supported OS/Architectures. At this point, I would like to pursue a sequence set of releases for these repos. based upon their dependencies. I would propose a 1.2 release of the Openwhisk Go client followed by a release of Whisk Deploy (which will reference the 1.2 Go client) followed by a release of the OpenWhisk CLI to 1.2 (which would ref. the 1.2 Go Client and the 1.2 Whisk Deploy repo.). Would there be any issue in executing against this plan? PS I see the Deno runtime may release soon; if someone will champion that release quickly, I could make sure Whisk Deploy and CLI 1.2 releases would account for that new runtime. Cheers, Matt
Re: Welcome new committer: Brendan Doyle
Warm welcome Brendan! Regards, Matt From: Rodric Rabbah To: dev@openwhisk.apache.org Date: 10/01/2020 08:17 AM Subject:[EXTERNAL] Welcome new committer: Brendan Doyle The Project Management Committee (PMC) for Apache OpenWhisk has invited Brendan Doyle to become a committer and we are pleased to announce that he has accepted. Please join me in welcoming Brendan to his new role on the project. Brendan has been contributing to improving the OpenWhisk deployment and operations, and helping out with reviews of significant new feature development. Thank you Brendan. -r
Re: [DISCUSS] Release"cli" group of modules
+1 Can confirm I am quite pleased with the 1.15 updates and move to gomod for both wskdeploy and cli proper and thanks Dave! On 2020/09/25 13:43:29, "David P Grove" wrote: > > I think the upgrade to go 1.15 has been completed (please correct me if I > am wrong). > > Therefore I would like to start the release process to prepare version > 1.1.0 of the three git repos: openwhisk-client-go, openwhisk-wskdeploy, > openwhisk-cli. > > --dave >
Re: What to do of go runtime and the proxy?
Avoid 1.14 for productions/releases (skip to 1.15) is what I would advise based upon feedback from our container runtime experts... Posted specifics in the PR which I assume prompted this post... https://github.com/apache/openwhisk-runtime-go/pull/128 In 1.15, the put retries (loops) and other safety measure within the lower level system libs. to correct for most of the exposures. -mr From: "Michele Sciabarra" To: dev@openwhisk.apache.org Date: 08/24/2020 03:31 PM Subject:[EXTERNAL] What to do of go runtime and the proxy? In the Go runtime it was mentioned in a comment that versions of go before 1.15 are unsafe. What is exactly the problem? Should we then drop runtimes for go from 1.11 to 1.14? Whar about the proxies for other languages? They are built with older versions of Go, should we change all tbe runtimes that uses the go proxy to build with go 1.15? -- Michele Sciabarra mich...@sciabarra.com
Has the Tecnical Interchange call been dropped?
It seems that after the Zoom bomb and password protecting the call, the next call attendance was so low that I do not believe that the facilitator nominated a host for the next call. Is the intent to let the call fall by the wayside (as it seemed quite energized before the simple password was added)? -MR
Tech. Interchange Videos (plural) posted from today's meeting
Thanks Rodric for hosting. Thanks everyone for the great presentations on some amazing new features/enrichments/uses of OpenWhisk; I hope (emphasis) to find time to try out personally some of them... Due to "technical difficulties" (ahem), our meeting today is captured in two YouTube videos: 2020-04-29 OW Technical Interchange Mtg - Part 1: https://youtu.be/RnXoHJHIUEM 2020-04-29 OW Technical Interchange Mtg - Part 2: https://youtu.be/gbUZsVdXff0 Dave volunteered to host the next iteration; we will provide an updated Zoom link and passcode for the next call (so you will need to get it from the Wiki and/or our Google calendar)... Cheers, mr
YouTube of today's tech int. call
Thanks Neeraj for hosting, and Rodric for volunteering for the 29th. https://youtu.be/uw-HhZAYGJU -mr
Re: [wskcli] Delete all entities in a namespace
I can testify to the "race" conditions... you can look in wskdeploy to see what we had to do including adding default 3 retries for each client call. Triggers and Rules are the worst... there may be special logic there as well to try with waits imposed. On 2020/03/25 01:20:54, Nick Mitchell wrote: > i think the core problem is that there are several layers of collections, > but no bulk and no cursored operations against these collections: "all > actions", "actions in package"... retries and careful coding can work > around these. so it might be sufficient just do it "twice" (in the > openwhisk client npm, and in the go CLI). our code is open source. it's > still not 100% correct. we still get travis failures 1/100 times or so. > > On Tue, Mar 24, 2020 at 9:09 PM Carlos Santana wrote: > > > Hi Nick this is very useful even outside demos, I remember having a bash > > alias that it was 95% correct to delete all. > > > > Your proposing the heavy lifting is implemented on the server side > > controller API and the client/api just do a single http request “delete > > all” ? > > > > - Carlos Santana > > @csantanapr > > > > > On Mar 24, 2020, at 7:16 PM, Nick Mitchell wrote: > > > > > > we implemented this in https://github.com/kui-shell/oui > > > > > > some lessons learned. it's possible, but tricky, due to the loose > > semantics > > > of openwhisk delete-after-delete ordering, plus some bits of potential > > race > > > conditions with with list windowing. things may have improved since we > > > first implemented this, so keep that in mind: > > > > > > 1) if you have an action in a package; then you have to delete the > > actions > > > in the package before you can delete the package; but... if you issue the > > > package delete after the last action delete API call has returned, there > > > (at least used to be) a short window where the package delete would > > fail. i > > > think this depends upon the quorum configuration of your backend > > database. > > > so you may need to have retries here. > > > > > > 2) if you have more than 200 (or whatever the LIMIT config is of your > > > server) actions (c.f. packages, etc.), then you will need to manage the > > > windowing yourself. since the openwhisk API has no strong sense of > > cursors > > > (or does it now?), you have to be careful to fetch all windows before > > > initiating any deletes in any of the windows... > > > > > > there may be more issues, but this one was non-trivial to get right. > > after > > > doing all the work, "delete all" struck me as the kind of thing that > > should > > > be supported by the API directly. > > > > > > @starpit > > > > > >> On Tue, Mar 24, 2020 at 5:23 PM Will Plusnick > > wrote: > > >> > > >> Hello all! > > >> > > >> I've frequently found myself having to clear a namespace after working > > >> on a demo or when experimenting. I'll have a number of artifacts left > > >> in a namespace that I don't want to preserve. Right now, unless I used > > >> wskdeploy for deployment, I'm stuck manually deleting all of the > > >> actions, rules, etc. I want to propose adding a command to the > > >> namespace subcommand in the cli for deleting all the artifacts in a > > >> namespace. > > >> > > >> I envision the syntax for the command going something like: > > >> > > >> $ wsk namespace delete all > > >> This command will delete all entities in the namespace : > > >> > > >> Are you sure you want to proceed? Type '' to proceed: > > >> > > >> action: > > >> is deleted > > >> is deleted > > >> .. > > >> trigger: > > >> is deleted > > >> is deleted > > >> .. > > >> etc > > >> > > >> The user would then be prompted whether they really want to delete all > > >> of the entities in the namespace. They would need to type in a "danger > > >> phrase" such as the name of the namespace to avoid accidentally running > > >> the command. This is similar to deleting a github repo. If anything > > >> but the "danger phrase" is received then the operation is aborted. > > >> > > >> This is a feature I would find personally useful, and would like to > > >> add it to the cli. Does the community at large feel this is a useful > > >> feature? > > >> > > >> Thanks, > > >> Will > > >> > > >> > > >
Video posted from today's Tech. Int. call
Short and sweet... Attendees: Matt, Dave, Justin, Will YouTube: https://youtu.be/RDA0TbmGAlw -matt
REMINDER!: OW Technical Interchange call starts in ~ 1 hour from now
* Zoom: https://zoom.us/my/asfopenwhisk * 10am EDT - New York; 7am PDT - San Francisco; 3pm CET - Berlin/Rome; 2pm GMT; 11pm KST - Seoul; 10pm CST - Beijing; Plenty of room for ad-hoc topics today... -mr
Re: Welcome new committer: Neeraj Mangal
Welcome Neeraj! On 2020/03/13 04:13:13, Dragos Dascalita Haut wrote: > The Project Management Committee (PMC) for Apache OpenWhisk > has invited Neeraj to become a committer and we are pleased > to announce that he has accepted. > > Please join me in welcoming Neeraj to his new role on the project ! > > Neeraj has been contributing to the Kube deployment, the CLI, and the main > project. > >
Technical Interchange this Wednesday! Accepting topics/agenda items now!
Please feel free to reply to this thread with topics to add to the agenda for this week’s call. REMEMBER: The United States has undergone a time change; therefore, the meeting start time may be 1 hour earlier if your country region did not undergo such a change (yet). I believe the start times for this week’s call are: 10am EDT, New York 7am PDT, San Francisco 3pm CET, Berlin, Rome 2pm GMT 11pm KST, Seoul 10pm CST, Beijing Cheers, Matt PS Please check my time zone math against what I believe is the correct start time
Re: Welcome new committer Alex Klimetschek
Welcome Alex!
Video posted from today's tech. int. call
Thanks Justin for hosting! Matt volunteered to be the next "victim" (ahem host) and we will be experiencing a timezone (Spring time) adjustment for "daylight savings" for some regions.. PLEASE note that the meeting time moves with the US geo. so the 10am EST time will move one hour earlier effectively, if you live in a region that has not (yet) or does not adjust for "daylight" YouTube: https://youtu.be/UcmZ_653_pk Thanks, Matt PS grab the new Google cal. link from the Wiki as it should move./adjust auto. for you...
Re: Welcome new committer: Dan McWeeny
Welcome Dan! Very grateful for all your contributions and glad to have your experience which will help guide us as we take OW to the next level. -mr
Re: [VOTE] Accept wskdebug contribution from Adobe
+1 Many thanks to the Adobe team for all the work to get it to this point! On 2020/02/20 14:36:49, "David P Grove" wrote: > > > This is a call to vote to accept the donation of the wskdebug code base > from Adobe as discussed in [1]. This majority vote will remain open for at > least 72 hours. > > The IP clearance form [2] has been filed and I will initiate an IPMC IP > clearance vote shortly (in parallel with this vote). (Note that there > appears to be a lag in rebuilding the html version of the clearance at [2]; > consult the .xml file in svn [3] if you want to see the latest) > > If the vote is successful, we will create a new git repo, > openwhisk-wskdebug, to contain the donated code to allow the OpenWhisk > community to continue its development. > > --dave > > [1] > https://lists.apache.org/thread.html/3cb01abdf0a6a0f2d577d08ed687ab0c06918b7ce958a27b0654b145%40%3Cdev.openwhisk.apache.org%3E > [2] https://incubator.apache.org/ip-clearance/openwhisk-wskdebug.html > [3] > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/openwhisk-wskdebug.xml >
Video posted from today's community call
YouTube link: https://youtu.be/vIiaBecNUnc
Re: [VOTE] Release Apache OpenWhisk Runtime Dotnet (v1.14.0, rc1)
+1 Approve release of 'OpenWhisk Runtime Dotnet' 1.14.0 rc1 -Matt rcverify logs: Matthews-MacBook-Pro-4:verify Matt$ ./rcverify.sh openwhisk-runtime-dotnet 'OpenWhisk Runtime Dotnet' 1.14.0 rc1 rcverify.sh (script SHA1: 6227 B5B2 B8FE 80C3 4827 F4C9 3E1F 90AF A09A 3180) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.uxmff75T fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-runtime-dotnet-1.14.0-sources.tar.gz fetching openwhisk-runtime-dotnet-1.14.0-sources.tar.gz.asc fetching openwhisk-runtime-dotnet-1.14.0-sources.tar.gz.sha512 fetching release keys importing keys gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) " not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: key B1457C3D7101CC78: "James Thomas " not changed gpg: Total number processed: 4 gpg: unchanged: 4 unpacking tar ball cloning scancode Cloning into 'openwhisk-utilities'... remote: Enumerating objects: 55, done. remote: Counting objects: 100% (55/55), done. remote: Compressing objects: 100% (41/41), done. remote: Total 55 (delta 21), reused 30 (delta 11), pack-reused 0 Unpacking objects: 100% (55/55), done. computing sha512 for openwhisk-runtime-dotnet-1.14.0-sources.tar.gz SHA512: openwhisk-runtime-dotnet-1.14.0-sources.tar.gz: 2359D1BB 46C54D1A 5C637805 8D40E8D0 107F07B7 96C14B0C F9DE4CE8 B1A812DE DB9ACD86 1B37E72F 332AE5A2 00F23F63 63B931AF 07E96E7B 02288F8C A9EA9BD0 validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed run the following command to remove the scratch space: rm -rf '/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.uxmff75T'
Re: [VOTE] Release Apache OpenWhisk Catalog (v0.11.0, rc1)
+1 to release 0.11.0 rc1 of OpenWhisk Catalog. Confirmed with rcverify and manual inspection. -Matt logs: Matthews-MacBook-Pro-4:verify Matt$ ./rcverify.sh openwhisk-catalog 'OpenWhisk Catalog' 0.11.0 rc1 rcverify.sh (script SHA1: 6227 B5B2 B8FE 80C3 4827 F4C9 3E1F 90AF A09A 3180) working in the following directory: /var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.T6FrCUm3 fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/openwhisk/rc1 fetching openwhisk-catalog-0.11.0-sources.tar.gz fetching openwhisk-catalog-0.11.0-sources.tar.gz.asc fetching openwhisk-catalog-0.11.0-sources.tar.gz.sha512 fetching release keys importing keys gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) " not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: key B1457C3D7101CC78: "James Thomas " not changed gpg: Total number processed: 4 gpg: unchanged: 4 unpacking tar ball cloning scancode Cloning into 'openwhisk-utilities'... remote: Enumerating objects: 55, done. remote: Counting objects: 100% (55/55), done. remote: Compressing objects: 100% (41/41), done. remote: Total 55 (delta 21), reused 30 (delta 11), pack-reused 0 Unpacking objects: 100% (55/55), done. computing sha512 for openwhisk-catalog-0.11.0-sources.tar.gz SHA512: openwhisk-catalog-0.11.0-sources.tar.gz: BDFD6CBC B31D17CE 68167AFA 8C46024E 1586840B CCC36274 342B12E7 ADDCB3E1 3FE2E7AC 370DE4A6 7D971A07 C110C2D3 ABB3F233 6955EB06 5122C36E CC270BC6 validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for unexpected file types... passed scanning for archives... passed scanning for packages... passed run the following command to remove the scratch space: rm -rf '/var/folders/bc/p62kjnm12n9_l30qfxv7p9lcgn/T/tmp.T6FrCUm3'
RE: [proposal] remove vagrant support
+1 emphatically Kind regards, Matt
RE: Welcome new Committer Shawn Black
Welcome Shawn! Kind regards, Matt From: Rob Allen To: dev@openwhisk.apache.org Date: 12/03/2019 01:24 AM Subject:[EXTERNAL] Re: Welcome new Committer Shawn Black Welcome Shawn! Regards, Rob > On 2 Dec 2019, at 23:19, Rodric Rabbah wrote: > > It is my pleasure to share that the OpenWhisk PPMC has elected Shawn Black > as a Committer, based on his ongoing and valuable contributions to the > project around the .NET runtime. Shawn has accepted the invitation. > > Please join me in welcoming Shawn to his new role on the project. > > -r
Re: Notes+Video posted from today's Tech Int. call
Updated URL for meeting notes: https://cwiki.apache.org/confluence/display/OPENWHISK/2019-10-16+OW+Tech+Interchange+Meeting+Notes
Notes+Video posted from today's Tech Int. call
Thanks Rodric for hosting and Dave for being "next up". People who presented please upload presentations and/or update the meeting note with details. Exciting playground UI shown today! Video: https://youtu.be/O8zmSdmECBA Notes: https://cwiki.apache.org/confluence/display/OPENWHISK/Tech+Interchange+2019-10-16 Cheers, mr
RE: Porting Knative on Openwhisk
The functionality should still be available IMO... allowing for expanded use cases (and reuse) other than fixed, env.-only params. plus possibility of re-init. Kind regards, Matt From: "Michele Sciabarra" To: "Matt Rutkowski" , dev@openwhisk.apache.org Date: 10/10/2019 12:19 PM Subject:[EXTERNAL] Re: Porting Knative on Openwhisk Question: but does the "/init" and "/run" entry point should be still available? Also, why do you need to accept this init? Should not be an action built with tekton already ready to run, or you still have an initialization step? -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Matt Rutkowski To: dev@openwhisk.apache.org Subject: RE: Porting Knative on Openwhisk Date: Thursday, October 10, 2019 6:45 PM Hi Alessio, It should be noted that the JavaScript proxy (httpserver) under knative allows the single root "/" entry point to handle a JSON paylaod that includs "init", "run" or "init/run" together (along with parameter data) to separate logical data and avoid keyname collisins. In order to do this, we simply intrduced new top-level keys in the JSON payload to separate the "init" data from "run" (activation) data, as we already had a collision on the key "name". An example can be fund here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk-2Ddevtools_blob_master_knative-2Dbuild_runtimes_javascript_tests_helloworldwithparamsfromenv_payload-2Dknative-2Dinit-2Drun.http=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=J6qH6e_AHnGEmmrl77l_s6oi2p36x-FPnfDI6fzrZZM=uPcpeCuVI8-XjcsyL0WgVwOKigds8gS2P5XN-_9mebA= It should be noted that the changes needed to support these combinations was not easy in NodeJS as route handlers with Promises do not behave in a last-in first out manner and behave asynchronously (in case you were loooking at the code wondering why there was lots of duplication...). Much of the "experimental" work we did under https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk-2Ddevtools_tree_master_knative-2Dbuild=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=J6qH6e_AHnGEmmrl77l_s6oi2p36x-FPnfDI6fzrZZM=N0FX5uZxp85fUFr9BKwmHlSzXclsjpT2UvBC1JLJVlI= (and where we are working on Java optimizations as well) From: Alessio Marinelli To: Date: 10/10/2019 10:19 AM Subject:[EXTERNAL] Re: Porting Knative on Openwhisk ok, thanks, Alessio Il giovedì 10 ottobre 2019, 16:14:54 CEST, Michele Sciabarra ha scritto: Hi Alessio, thanks for your help. Basically, the task is to write implement in the runtime an adapter that will allow Knative images, that are basically simply http servers, to satisfy the contract of the OpenWhisk actions. There is already an implementation in Javascript here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk-2Druntime-2Dnodejs_blob_master_core_nodejsActionBase_platform_knative.js=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=tDM06Fqzo2uglMSzP9HARX04zWh6JG3-eJriGk8kSHw=eUkvQmN-dzBR0pzI5JspdtO1yO5bfqFHSV33m2yvPo8= The contract is split in /init and /run behaviour I already did the work for the init part although I have to change it to work in the same way the Javascript implementation works. I will take care of it. I would ask you to implement support of the /run part. Basically it means: - accepting an http request in the root path - create a single line json that encodes the values that an action expects, as described here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_actions-2Dnew.md=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=tDM06Fqzo2uglMSzP9HARX04zWh6JG3-eJriGk8kSHw=EiAAbhiVnCJZborUMymzxF2W1lYGYzn7SqTDIB5oXfA= (look for activation) - feed the json to the underlying action executor that is already running after the initalization - collect the answer and decode it in order to provide the expected http answer. For a web action it must implement the web action contract as described here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_webactions.md=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=tDM06Fqzo2uglMSzP9HARX04zWh6JG3-eJriGk8kSHw=JAkwVA0EusYnt8G53y4TXZrzYx2TddIUxFYC0oqAS0c= otherwise just return an action. The javascript knative.js code should provide a good guidance on the details. For anything else just ask, either here or on slack. Go the same implementation here: -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Alessio Marinelli To: "dev@openwhisk.apache.org" Subject: Porting Knative on Openwhisk D
RE: Porting Knative on Openwhisk
Hi Alessio, It should be noted that the JavaScript proxy (httpserver) under knative allows the single root "/" entry point to handle a JSON paylaod that includs "init", "run" or "init/run" together (along with parameter data) to separate logical data and avoid keyname collisins. In order to do this, we simply intrduced new top-level keys in the JSON payload to separate the "init" data from "run" (activation) data, as we already had a collision on the key "name". An example can be fund here: https://github.com/apache/openwhisk-devtools/blob/master/knative-build/runtimes/javascript/tests/helloworldwithparamsfromenv/payload-knative-init-run.http It should be noted that the changes needed to support these combinations was not easy in NodeJS as route handlers with Promises do not behave in a last-in first out manner and behave asynchronously (in case you were loooking at the code wondering why there was lots of duplication...). Much of the "experimental" work we did under https://github.com/apache/openwhisk-devtools/tree/master/knative-build (and where we are working on Java optimizations as well) From: Alessio Marinelli To: Date: 10/10/2019 10:19 AM Subject:[EXTERNAL] Re: Porting Knative on Openwhisk ok, thanks, Alessio Il giovedì 10 ottobre 2019, 16:14:54 CEST, Michele Sciabarra ha scritto: Hi Alessio, thanks for your help. Basically, the task is to write implement in the runtime an adapter that will allow Knative images, that are basically simply http servers, to satisfy the contract of the OpenWhisk actions. There is already an implementation in Javascript here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk-2Druntime-2Dnodejs_blob_master_core_nodejsActionBase_platform_knative.js=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=tDM06Fqzo2uglMSzP9HARX04zWh6JG3-eJriGk8kSHw=eUkvQmN-dzBR0pzI5JspdtO1yO5bfqFHSV33m2yvPo8= The contract is split in /init and /run behaviour I already did the work for the init part although I have to change it to work in the same way the Javascript implementation works. I will take care of it. I would ask you to implement support of the /run part. Basically it means: - accepting an http request in the root path - create a single line json that encodes the values that an action expects, as described here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_actions-2Dnew.md=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=tDM06Fqzo2uglMSzP9HARX04zWh6JG3-eJriGk8kSHw=EiAAbhiVnCJZborUMymzxF2W1lYGYzn7SqTDIB5oXfA= (look for activation) - feed the json to the underlying action executor that is already running after the initalization - collect the answer and decode it in order to provide the expected http answer. For a web action it must implement the web action contract as described here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_webactions.md=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=tDM06Fqzo2uglMSzP9HARX04zWh6JG3-eJriGk8kSHw=JAkwVA0EusYnt8G53y4TXZrzYx2TddIUxFYC0oqAS0c= otherwise just return an action. The javascript knative.js code should provide a good guidance on the details. For anything else just ask, either here or on slack. Go the same implementation here: -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Alessio Marinelli To: "dev@openwhisk.apache.org" Subject: Porting Knative on Openwhisk Date: Thursday, October 10, 2019 4:02 PM Hi I am a colleague of Michele and I would like to help you complete the Knative support for actionloop, any indication will be appreciated, thanks, Alessio.
2019-10-02 Tech Int. Notes and video posted
Thanks Dom for hosting. Need to keep promoting the new, hour earlier, timeslot... Notes: https://cwiki.apache.org/confluence/display/OPENWHISK/2019-10-02+W+Tech+Interchance+-+Meeting+Notes Video: https://youtu.be/r5J0SzCIv6g Additional thanks to Rodric for volunteering to host the next meeting on Oct. 16th. Cheers, mr
Re: [VOTE] Release Apache OpenWhisk Command-line Interface (CLI), OpenWhisk Client Go, OpenWhisk Wskdeploy (v1.0.0, rc1)
Thanks Dave, +1 for the releasing the CLI, Client Go and Whisk Deploy components at 1.0.0 level PS: If anyone is touching the rcverify.sh file please fix the typo in the "verifing notice..." (string). here are my local verification logs: >> Matt$ ./rcverify.sh openwhisk-cli 'OpenWhisk Command-line Interface (CLI)' >> 1.0.0 >> gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) >> " not changed >> gpg: key 22907064147F886E: "Dave Grove " not changed >> gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed >> gpg: key B1457C3D7101CC78: "James Thomas " not >> changed >> gpg: unchanged: 4 >> computing sha512 for openwhisk-cli-1.0.0-sources.tar.gz >> SHA512: openwhisk-cli-1.0.0-sources.tar.gz: >> 511306A7 DB5483B2 4BAEACE9 5A797CB6 9CDD12B3 028899C3 0066746E E19B318E >> 5F8331CE 6E0008C1 8AEE1B47 4A6E8FCA F8AADD80 47C66A52 1D261E22 D2530CA9 >> validating sha512... passed >> verifying asc... passed (signed-by: Dave Grove ) >> verifing notice... passed >> verifying absence of DISCLAIMER.txt passed >> verifying license... passed >> verifying sources have proper headers... passed >> scanning for executable files... passed >> scanning for unexpected file types... passed >> scanning for archives... passed >> scanning for packages... passed --- >> Matt$ ./rcverify.sh openwhisk-client-go 'OpenWhisk Client Go' 1.0.0 rc1 >> importing keys >> gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) >> " not changed >> gpg: key 22907064147F886E: "Dave Grove " not changed >> gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed >> gpg: key B1457C3D7101CC78: "James Thomas " not >> changed >> gpg: unchanged: 4 >> computing sha512 for openwhisk-client-go-1.0.0-sources.tar.gz >> SHA512: openwhisk-client-go-1.0.0-sources.tar.gz: >> F4217B91 26E63251 CE5B256D 7D1DDBE2 72C59A35 F4AFA319 E4AD6D78 89E9CCA4 >> AD9C5788 038D429C 305D471C A24129A8 AC91A863 2668D7BC B01556DF CF5403A9 >> validating sha512... passed >> verifying asc... passed (signed-by: Dave Grove ) >> verifing notice... passed >> verifying absence of DISCLAIMER.txt passed >> verifying license... passed >> verifying sources have proper headers... passed >> scanning for executable files... passed >> scanning for unexpected file types... passed >> scanning for archives... passed >> scanning for packages... passed --- >> Matt$ ./rcverify.sh openwhisk-wskdeploy 'OpenWhisk Client Go' 1.0.0 rc1 >> importing keys >> gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) >> " not changed >> gpg: key 22907064147F886E: "Dave Grove " not changed >> gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed >> gpg: key B1457C3D7101CC78: "James Thomas " not >> changed >> gpg: unchanged: 4 >> computing sha512 for openwhisk-wskdeploy-1.0.0-sources.tar.gz >> SHA512: openwhisk-wskdeploy-1.0.0-sources.tar.gz: AB9A8F0F 8520384A 9CA4F938 AA23378C BF2BB45A 52B91BAE 450509BC A6EFACC7 993CEF1F 62C403B8 C80B7A19 8B8EBBAA 2EBD2E97 CEC2309A CC637827 FEA3220B >> validating sha512... passed >> verifying asc... passed (signed-by: Dave Grove ) >> verifing notice... passed >> verifying absence of DISCLAIMER.txt passed >> verifying license... passed >> verifying sources have proper headers... passed >> scanning for executable files... passed >> scanning for unexpected file types... passed >> scanning for archives... passed >> scanning for packages... passed On 2019/09/17 13:26:17, "David P Grove" wrote: > > > Hi, > > This is a call to vote on releasing version 1.0.0 release candidate rc1 of > the following 3 project modules with artifacts built from the Git > repositories and commit IDs listed below. > > * OpenWhisk Command-line Interface (CLI): > 5ad2291882e1d89ecd8c377dd1ffb1fe1043bf07 > > https://github.com/apache/openwhisk-cli/commits/5ad2291882e1d89ecd8c377dd1ffb1fe1043bf07 > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-1.0.0-rc1/openwhisk-cli-1.0.0-sources.tar.gz > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-1.0.0-rc1/openwhisk-cli-1.0.0-sources.tar.gz.asc > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-1.0.0-rc1/openwhisk-cli-1.0.0-sources.tar.gz.sha512 > > * OpenWhisk Client Go: 716c6f973eb297b39e764938284350050f3d3974 > > https://github.com/apache/openwhisk-client-go/commits/716c6f973eb297b39e764938284350050f3d3974 > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-1.0.0-rc1/openwhisk-client-go-1.0.0-sources.tar.gz > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-1.0.0-rc1/openwhisk-client-go-1.0.0-sources.tar.gz.asc > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-1.0.0-rc1/openwhisk-client-go-1.0.0-sources.tar.gz.sha512 > > * OpenWhisk Wskdeploy: fff873eaf189071e28e9d29deab26a7270027f14 > > https://github.com/apache/openwhisk-wskdeploy/commits/fff873eaf189071e28e9d29deab26a7270027f14 > >
[NOTICE] OW Tech. Interchange Mtg. start time changed (1 hour earlier)
Whiskers, As a result of the discussion on the thread titled: "Can we adjust the time for the community call" see: https://lists.apache.org/thread.html/1f7f9422762234edf4321c29c7f878cc09e60cca571364bd9b6da84a@%3Cdev.openwhisk.apache.org%3E and subsequent polling to find a better start time for our current active members, we have decided to assume lazy consensus and move the start time for our Wednesday, bi-weekly Technical Interchange call to be one hour earlier than previously scheduled. The information for the start time has been updated on the Wiki home page and reads as follows: >> Web Meeting: Tech Interchange (bi-weekly; on May 9th / off May 16th, etc.): >> Day-Time: Wednesdays, 10AM EDT (Eastern US, New York), 4PM CEST (Central >> Europe, Berlin), 2PM GMT, 10PM (CST, Beijing) Please use the link to save the new calendar entry from our project calendar to your calendar. >> Google Calendar (click link to add to your calendar): https://calendar.google.com/event?action=TEMPLATE=dGEyOWRqdXYxbzFpbTFrbzcxa3VvaXE0amhfMjAxOTEwMDJUMTQwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ=apacheopenwhisk%40gmail.com=ALL It is our hope that our attendance will be stronger than ever with this change and enable more informed discussions on many design topics as we seek to further the reach of the OpenWhisk platform. Cheers, Matt PS Wiki home: https://cwiki.apache.org/confluence/display/OPENWHISK/Apache+OpenWhisk+Project+Wiki
Video posted from today's Tech Int call
Excellent topics today! Video: https://youtu.be/jiBjjngny64 Notes: TBD (will append link to this thread shortly) Dan M. showed an early "experimental" router using Azure Knative cluster to schedule Action against a known pool of "stem cell" pods using the CLI... (Dan also made the "cover" image for the mtg. video). Matt showed Java JVM cache "profile" optimization work that will also be used in Tekton build pipelines to help devs create Archives or Docker image (runtimes) from source. NOTE: We also decided (assume lazy consensus) will CHANGE the time for the Tech. Int. call to one hour earlier starting next call (Oct. 2) and make announcements. Thanks Dom for leading polling and providing options. Thanks Dom also for volunteering to host the Oct. 2nd call at its new earlier time. Cheers, Matt
Please submit topics for this week's (Wed. 18th) Tech. Interchange call!
Hello Whiskers! Please submit items for agenda for this Wednesday’s (Sept 18) Tech Interchange call. Some topics I already have "penciled in" include: * Proposal for new Tech. Int. Meeting time(s) - Dom * JVM Pre-cache optimization work in Java runtime - Matt * OpenWhisk Tekton Pipeline update - Priti Looking forward! Matt Day-Time: Wednesday Sept 18, 11AM EDT (Eastern US), 5PM CEST (Central Europe), 3PM GMT, 11PM (Beijing) Zoom: https://zoom.us/my/asfopenwhisk
RE: [DISCUSS}: release "cli group" of projects
+1 Thank you Chetan. wskdeploy has had a few bug fixes and is due release... Kind regards, Matt From: Chetan Mehrotra To: dev@openwhisk.apache.org Date: 09/15/2019 11:23 PM Subject:[EXTERNAL] Re: [DISCUSS}: release "cli group" of projects +1 for version 1.0 for cli projects Chetan Mehrotra On Sat, Sep 14, 2019 at 5:43 AM Carlos Santana wrote: > > +1 and version 1.0 > > - Carlos Santana > @csantanapr > > > On Sep 13, 2019, at 10:46 AM, Rodric Rabbah wrote: > > > > +1 for for 1.0 > > > >> On Fri, Sep 13, 2019 at 10:23 AM David P Grove wrote: > >> > >> > >> > >> I'd like to make a release of the 3 "cli group" projects: > >> openwhisk-client-go, openwhisk-wskdeploy, openwhisk-cli. > >> > >> The main motivation is to pick up the fix for a bug [1] in wskdeploy, which > >> causes the `wsk project` subcommand to crash in some common usage scenarios > >> in the 0.10.0 release. > >> > >> It looks to me like the current master branch is stable with no pending PRs > >> that need to be merged. If I missed something, please comment on this > >> thread. > >> > >> One item for discussion is whether we should number this release as 0.11.0 > >> or go ahead and call it 1.0.0. To me it seems like the cli api is fairly > >> stable, so going to a 1.x.y numbering seems plausible. But I don't work on > >> the cli tools, so I might be overlooking a reason to stay with a 0.x > >> number. > >> > >> thanks, > >> > >> --dave > >> > >> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk-2Dwskdeploy_issues_1050=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=Pv7ochOdddqGbBq0sL3fWGQbIs511mcmTeSDL8ZdQ90=1AxIX5kCHYfJ5dAQPYEgVuBEOwjpR3OADEE-UPZmD7o= > >>
RE: Can we adjust the time for the community call
Pursuing alternating times may be a good choice, but would like to know we have a reliable person to host (fallback) for these slots as our "volunteer" mechanism is barely functioning for the current call/time. Dom, perhaps you can post a poll for contribs. to vote on; perhaps this would give us a sense of who is paying attention, what suits them and get a ballpark on how many would benefit? Kind regards, Matt From: Tyson Norris To: "dev@openwhisk.apache.org" Date: 09/05/2019 10:40 AM Subject:[EXTERNAL] Re: Can we adjust the time for the community call US West coast dweller here - I'm OK with either 1 hour ealier, or alternating times. Anything to get more players on the field :) Thanks Tyson On 9/5/19, 3:53 AM, "Rodric Rabbah" wrote: Thanks Dominic for bringing this up. +1 from me. What about alternating times (every two weeks) so other time zones aren't always so late in the day? -r On Wed, Sep 4, 2019 at 11:27 PM Dominic Kim wrote: > Dear community members. > > I wonder whether we can set up our Tech. Int. meeting 1-hour earlier. > Currently, we hold the meeting at 3 PM GMT which is 12:00 AM KST/JST. > > If we hold the meeting 1-hour earlier, the time changes like this: > > - 2 PM GMT. > - 10 AM US eastern time > - 10 CST > - 11 KST/JST > > One issue is the US western time would be 7 AM. > So if anyone lives in that area, I would give up. > > But if it's fine for most of the members, I hope we start the meeting > 1-hour earlier. > It would help me and other folks living in Korea/Japan to join the meeting > better. > > > Best regards > Dominic >
Notes+Video posted from today's Tech. Int. meeting
Thanks Tyson for hosting... including an interesting proposal for a new "router" allowing delegation to multiple Execution Providers (e.g, classic OW, Knative, V8 isolates) and perhaps dropping as an "experimental" part of the core/main OW repo. soon... Notes: https://cwiki.apache.org/confluence/display/OPENWHISK/2019-09-04+OW+Tech+Interchange+Meeting+Notes Video: https://youtu.be/-UxrRHysPLs Matt volunteered to host next iteration... PS video from 8-21-2019 call posted as well (sorry as Matt was on vacation): https://youtu.be/cC88BXvUHjc
RE: [DISCUSS] release openwhisk-apigateway 0.11.0
+1 agreed From: Matt Hamann To: dev@openwhisk.apache.org Date: 08/22/2019 10:22 PM Subject:[EXTERNAL] Re: [DISCUSS] release openwhisk-apigateway 0.11.0 I concur with this. Should be good to go. - Matt On Thu, Aug 22, 2019 at 5:10 PM David P Grove wrote: > > We need to make a new release of apigateway to get support for the > standalone configuration of OpenWhisk into an official release. > > It looks to me like the current tip of the master branch is in good shape > to release. Unless there are objections, I will build a release candidate > and kick off a vote over the upcoming weekend. > > --dave >
Re: stricter scancode: now rejecting minified license headers
Headers to full... https://github.com/apache/incubator-openwhisk/pull/4568 On 2019/07/24 15:04:33, "David P Grove" wrote: > > > I just merged [1] which enforces the stricter license header conventions in > scancode (only use full header, not minified) that we discussed on the dev > list about a month ago. Matt has gone through a large number of repos and > updated all the license headers, so hopefully we are ready for the stricter > rules. > > --dave > > [1] https://github.com/apache/incubator-openwhisk-utilities/pull/65 >
RE: stricter scancode: now rejecting minified license headers
I have a stricter config ready to go in a local branch... can remove "tests" and other exclusions (but it will have more impacts am sure). Kind regards, Matt From: Rodric Rabbah To: dev@openwhisk.apache.org Date: 07/24/2019 10:31 AM Subject:[EXTERNAL] Re: stricter scancode: now rejecting minified license headers The scancode configuration is excluding the tests/data/actions directory. Since we're not bundling tests in the releases, I suppose that was OK in the past. But we should be including tests, and in any case we should remove this exclusion and review the scan code exclusions to make sure they're not too loose. # Exclude from incubator-openwhisk # Jenkins/test generated reports # Test data. # Generated binary artifacts tests/build/reports tests/dat/actions docs/images bin On Wed, Jul 24, 2019 at 11:25 AM Rodric Rabbah wrote: > We've got a gap somewhere. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_blob_master_tests_dat_actions_argsPrint.js=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=Sbnkas1JnvA9FulU7yjaXsyVZ7SjCTmsdXtpqXu5PyA=NDdGKptuO67qQq4mh9-nVT47cDgGtRtq1rOoTV_5cww= > and several other js files in the tests use the short license. > > -r > > On Wed, Jul 24, 2019 at 11:04 AM David P Grove wrote: > >> >> >> I just merged [1] which enforces the stricter license header conventions >> in >> scancode (only use full header, not minified) that we discussed on the dev >> list about a month ago. Matt has gone through a large number of repos >> and >> updated all the license headers, so hopefully we are ready for the >> stricter >> rules. >> >> --dave >> >> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dutilities_pull_65=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=Sbnkas1JnvA9FulU7yjaXsyVZ7SjCTmsdXtpqXu5PyA=r4z3anoMuZhkKKSgaZNGDj3EyQhjC1JglyXLJt5ayPE= >> >
Video+notes posted from today's tech. int. call
First post-grad. meeting! video: https://youtu.be/x_MtqtYyLQw notes: https://cwiki.apache.org/confluence/display/OPENWHISK/2019-07-24+OW+Tech+Interchange+-+Meeting+Notes Chetan kindly agreed to host the next call sched. for Aug. 7th
Agenda for Tech. Int. call today
Any more topics? Scanning PR and dev lists here are the topics I gleaned: * PR review (e.g., Rodric/Carlos//Tyson, etc.) * [Scheduler] Initial commit for Scheduler #4547 (Dom) * https://github.com/apache/incubator-openwhisk/pull/4547 * TBD * Add option for appending runtimes registry to user provided images #4503 (duynguyen) * https://github.com/apache/incubator-openwhisk/pull/4503 * TBD * Close the consumer when WakeupExcpetion happened #4459 * https://github.com/apache/incubator-openwhisk/pull/4459 * Merge? * TBD * Delete pod when creating timeout #4424 * https://github.com/apache/incubator-openwhisk/pull/4424 * Merge? * TBD * Change prewarm container #4225 * https://github.com/apache/incubator-openwhisk/pull/4225 * Needs rebase/conflicts fixed... * TBD * Dev List * Housecleaning of Git repos. (Dave) * https://lists.apache.org/thread.html/f490294036f0e2ae8536966c2f2e8f8e7986646b487753cc467c89a4@%3Cdev.openwhisk.apache.org%3E * remove “incubator-“; can we deprecate any before? * TBD * Apache OW client release (James) * https://lists.apache.org/thread.html/b67abc6a090ff888588865fe59063699ef0aa10b6f6bd8841267ce90@%3Cdev.openwhisk.apache.org%3E * TBD * OW Invoker overloads - “Resched. run” (Sven) * https://lists.apache.org/thread.html/6f0a809584f4bfe712669550ffd99a129202e146235e7c0f75595cd6@%3Cdev.openwhisk.apache.org%3E * TBD * A direction to take in a new component, "the scheduler” (Dom) * https://lists.apache.org/thread.html/c67a883f893fab8a40ed34b78696451ad5bc55dee693618a3013c460@%3Cdev.openwhisk.apache.org%3E * TBD * Updating our contributions guide (Rodric) * https://lists.apache.org/thread.html/27cc7bb9449d3b87e4fc6353455eaae4e1b9d200c923d4f26e74ee77@%3Cdev.openwhisk.apache.org%3E * TBD * Openwhisk in a standalone runnable jar (#4516) (Chetan) * https://lists.apache.org/thread.html/5d207a2cef5b6b3b79695633d0206d94fee0c08aa09c746826e0610f@%3Cdev.openwhisk.apache.org%3E * Impacts on website, OW README “getting started”? * Any update?
Re: [REMINDER] Technical Interchange Call TOMORROW! submit topics!
Topics anyone? scanning PR and dev lists here are the topics I gleaned: * PR review (e.g., Rodric/Carlos//Tyson, etc.) * [Scheduler] Initial commit for Scheduler #4547 (Dom) * https://github.com/apache/incubator-openwhisk/pull/4547 * TBD * Add option for appending runtimes registry to user provided images #4503 (duynguyen) * https://github.com/apache/incubator-openwhisk/pull/4503 * TBD * Close the consumer when WakeupExcpetion happened #4459 * https://github.com/apache/incubator-openwhisk/pull/4459 * Merge? * TBD * Delete pod when creating timeout #4424 * https://github.com/apache/incubator-openwhisk/pull/4424 * Merge? * TBD * Change prewarm container #4225 * https://github.com/apache/incubator-openwhisk/pull/4225 * Needs rebase/conflicts fixed... * TBD * Dev List * Housecleaning of Git repos. (Dave) * https://lists.apache.org/thread.html/f490294036f0e2ae8536966c2f2e8f8e7986646b487753cc467c89a4@%3Cdev.openwhisk.apache.org%3E * remove “incubator-“; can we deprecate any before? * TBD * Apache OW client release (James) * https://lists.apache.org/thread.html/b67abc6a090ff888588865fe59063699ef0aa10b6f6bd8841267ce90@%3Cdev.openwhisk.apache.org%3E * TBD * OW Invoker overloads - “Resched. run” (Sven) * https://lists.apache.org/thread.html/6f0a809584f4bfe712669550ffd99a129202e146235e7c0f75595cd6@%3Cdev.openwhisk.apache.org%3E * TBD * A direction to take in a new component, "the scheduler” (Dom) * https://lists.apache.org/thread.html/c67a883f893fab8a40ed34b78696451ad5bc55dee693618a3013c460@%3Cdev.openwhisk.apache.org%3E * TBD * Updating our contributions guide (Rodric) * https://lists.apache.org/thread.html/27cc7bb9449d3b87e4fc6353455eaae4e1b9d200c923d4f26e74ee77@%3Cdev.openwhisk.apache.org%3E * TBD * Openwhisk in a standalone runnable jar (#4516) (Chetan) * https://lists.apache.org/thread.html/5d207a2cef5b6b3b79695633d0206d94fee0c08aa09c746826e0610f@%3Cdev.openwhisk.apache.org%3E * Impacts on website, OW README “getting started”? * Any update? On 2019/07/23 16:31:33, "Matt Rutkowski" wrote: > Web Meeting: Tech Interchange (bi-weekly): > Day-Time: Wednesdays, 11AM EDT (Eastern US), 5PM CEST (Central Europe), > 3PM GMT, 11PM (midnight)(Beijing) > Zoom: https://zoom.us/my/asfopenwhisk > Google Calendar (click entry to add): > https://calendar.google.com/event?action=TEMPLATE=MnU2dHNiMjc0bTRoc29ydjBscW05Ym1jNmhfMjAxOTA5MDRUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ=apacheopenwhisk%40gmail.com=ALL > >
[REMINDER] Technical Interchange Call TOMORROW! submit topics!
Web Meeting: Tech Interchange (bi-weekly): Day-Time: Wednesdays, 11AM EDT (Eastern US), 5PM CEST (Central Europe), 3PM GMT, 11PM (midnight)(Beijing) Zoom: https://zoom.us/my/asfopenwhisk Google Calendar (click entry to add): https://calendar.google.com/event?action=TEMPLATE=MnU2dHNiMjc0bTRoc29ydjBscW05Ym1jNmhfMjAxOTA5MDRUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ=apacheopenwhisk%40gmail.com=ALL
Re: Re: Updating our contributions guide
IMO, CLAs should be required for any non-trivial contributions (as in-effect IP is being added and their contributions have to be done within a legal framework that preserves the overall code license) and our wording should better clarify (with examples, what qualifies). The question, for the kafka example you cited, is if the boxed (linked from the other page; an indirection) disclaimer on their wiki here: https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes provides the legal protections they believe it does. or can someone say "i missed reading that", "never saw that link", "i never explicitly agreed to that" (i.e., is it legally binding)? From: James Thomas To: dev@openwhisk.apache.org Date: 07/16/2019 07:29 AM Subject:[EXTERNAL] 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.apache.org_licenses_contributor-2Dagreements.html-23clas=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=3FzsaU7BJAW77yLUILNEb313M3Hryq1dEyTL4U6L880=RHH3dpGAxPV7uUZ9Gjg8iZOL4aLq5BHQx4IkGZ3BTxk= > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__kafka.apache.org_contributing.html=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=3FzsaU7BJAW77yLUILNEb313M3Hryq1dEyTL4U6L880=py_uMLrJNvQ90_r-jpkOdsCP4vX5H9CU0ZF9tdnBGA4= https://urldefense.proofpoint.com/v2/url?u=https-3A__cordova.apache.org_contribute_contribute-5Fguidelines.html=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=3FzsaU7BJAW77yLUILNEb313M3Hryq1dEyTL4U6L880=C23JKl6FgWRNwCj-qYYzfHuaegdyuwU0ZwPW7zkUA9A= https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_couchdb_blob_master_CONTRIBUTING.md=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=3FzsaU7BJAW77yLUILNEb313M3Hryq1dEyTL4U6L880=NTcHIYRrcGhwOg8PF45UShU5VaQFL5R0EnTmyhR_nTU= I've also discovered this blog post ( https://urldefense.proofpoint.com/v2/url?u=https-3A__apetro.ghost.io_apache-2Dcontributors-2Dno-2Dcla_=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=3FzsaU7BJAW77yLUILNEb313M3Hryq1dEyTL4U6L880=mEW6RAODS_x7XwfTNZPTzNcRcGTnRxYc8osk29yXyJw= ) which looks at this issue and links to a mailing list thread: https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_www-2Dinfrastructure-2Ddev_201112.mbox_-253CA603FFCE-2D623B-2D43E9-2D87F8-2D39BAA51C72D1-40gbiv.com-253E=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=3FzsaU7BJAW77yLUILNEb313M3Hryq1dEyTL4U6L880=ef188SR8Xh200v3k6-Bh9-Evae9T_fK7bHZrsLnkrAI= 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: Re: Changing JavaScript SDK NPM Module Name: openwhisk => apache-openwhisk?
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
Fw: Welcome new PPMC members
Welcome Michele and Rob! - Forwarded by Matt Rutkowski/Austin/IBM on 07/15/2019 11:55 AM - From: Rodric Rabbah To: dev@openwhisk.apache.org Date: 07/15/2019 11:44 AM Subject:[EXTERNAL] Welcome new PPMC members It is my pleasure to share that the OpenWhisk PPMC voted to invite Rob Allen and Michele Sciabarra as new PPMC members based on their ongoing and valuable contributions to the project. They have both accepted the invitation. Rob and Michele were already project committers. Please join me in welcoming them to this new role on the project! -r
Re: Using Rust for the KnativeWhisk controller
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 >
Re: website build broken
Hi Chris, Checked today and ... the OpenWhisk website builds are still failing to find NPM installed (build 239 logs show same failure when reported the issue for build 237): https://builds.apache.org/view/O/view/OpenWhisk/job/OpenWhisk-website/239/execution/node/9/log/ Is there anything more that can be done on your end to get our node setup with NPM as it was previously? Kind regards, Matt
Re: website build broken
Build is still broken on npm (build 239 same as 237 when reported): https://builds.apache.org/view/O/view/OpenWhisk/job/OpenWhisk-website/239/execution/node/9/log/ On 2019/07/09 18:56:52, Chris Lambertus wrote: > I’ve added the npm package to the puppet config, it should get automatically > installed in ~30 minutes or so. > > > > > On Jul 9, 2019, at 11:52 AM, Matt Rutkowski wrote: > > > > Apache build team, > > > > It appears that recently that our Jenkins jobs for building and publishing > > our project website for OpenWhisk has been failing (master) since mid-June > > (on "websites" node). The absence of the npm utility (plug-in) seems to > > be the culprit and was available to us w/o issue until around that time > > (in our groovy script) and a necessary part of building our static site > > from Jekyll. > > > > Can npm be added back? > > > > Thanks, > > Matt > > > > - Forwarded by Matt Rutkowski/Austin/IBM on 07/09/2019 01:46 PM - > > > > From: "David P Grove" > > To: "OpenWhisk Dev" > > Date: 07/09/2019 08:10 AM > > Subject:[EXTERNAL] website build broken > > > > > > > > > > The Jenkins job to rebuild the openwhisk website on commits to > > incubator-openwhisk-website is broken (succeeded on 6/14, next build on > > 7/3 > > failed as did a build today). > > > > It looks like a change in the Jenkins build environment. The script is > > not > > able to find npm [1]. Did we break this when attempting to do the other > > updates to our worker nodes? > > > > + npm install > > /home/jenkins/jenkins-slave/workspace/OpenWhisk-website@tmp/durable-c5656c4f/script.sh: > > line 16: npm: command not found > > > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_O_view_OpenWhisk_job_OpenWhisk-2Dwebsite_237_console=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=ZKLz58mIn2zpsvWZbrrzeSIdKrAZ0G-jmlP0PUpB3Q4=eyw9S7AgkN_zJhPf5ynyHAs2J5FMpvGqa3ndNeH6Y3A= > > > > > > > > > > > >
Re: Apologies, no Tech. Int call today
Created new Google cal. entry for 2H2019 (and posted to Wiki home page as well): https://calendar.google.com/event?action=TEMPLATE=MnU2dHNiMjc0bTRoc29ydjBscW05Ym1jNmhfMjAxOTA5MDRUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ=apacheopenwhisk%40gmail.com=ALL Please add it to your calendar (as I just did ;) On 2019/07/10 19:00:27, Matt Rutkowski wrote: > The recurring meeting dropped off my local calendar and I had an area meeting > which occupied my mind today so did not see the Slack reminder either. > > Please forgive and plan to resume in 2 weeks, Wed. July 24th; feel free to > submit topics anytime before then. > > -Matt >
Apologies, no Tech. Int call today
The recurring meeting dropped off my local calendar and I had an area meeting which occupied my mind today so did not see the Slack reminder either. Please forgive and plan to resume in 2 weeks, Wed. July 24th; feel free to submit topics anytime before then. -Matt
Re: website build broken
Thanks Chris! On 2019/07/09 18:56:52, Chris Lambertus wrote: > I’ve added the npm package to the puppet config, it should get automatically > installed in ~30 minutes or so. > > > > > On Jul 9, 2019, at 11:52 AM, Matt Rutkowski wrote: > > > > Apache build team, > > > > It appears that recently that our Jenkins jobs for building and publishing > > our project website for OpenWhisk has been failing (master) since mid-June > > (on "websites" node). The absence of the npm utility (plug-in) seems to > > be the culprit and was available to us w/o issue until around that time > > (in our groovy script) and a necessary part of building our static site > > from Jekyll. > > > > Can npm be added back? > > > > Thanks, > > Matt > > > > - Forwarded by Matt Rutkowski/Austin/IBM on 07/09/2019 01:46 PM - > > > > From: "David P Grove" > > To: "OpenWhisk Dev" > > Date: 07/09/2019 08:10 AM > > Subject:[EXTERNAL] website build broken > > > > > > > > > > The Jenkins job to rebuild the openwhisk website on commits to > > incubator-openwhisk-website is broken (succeeded on 6/14, next build on > > 7/3 > > failed as did a build today). > > > > It looks like a change in the Jenkins build environment. The script is > > not > > able to find npm [1]. Did we break this when attempting to do the other > > updates to our worker nodes? > > > > + npm install > > /home/jenkins/jenkins-slave/workspace/OpenWhisk-website@tmp/durable-c5656c4f/script.sh: > > line 16: npm: command not found > > > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_O_view_OpenWhisk_job_OpenWhisk-2Dwebsite_237_console=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=ZKLz58mIn2zpsvWZbrrzeSIdKrAZ0G-jmlP0PUpB3Q4=eyw9S7AgkN_zJhPf5ynyHAs2J5FMpvGqa3ndNeH6Y3A= > > > > > > > > > > > >
Fw: website build broken
Apache build team, It appears that recently that our Jenkins jobs for building and publishing our project website for OpenWhisk has been failing (master) since mid-June (on "websites" node). The absence of the npm utility (plug-in) seems to be the culprit and was available to us w/o issue until around that time (in our groovy script) and a necessary part of building our static site from Jekyll. Can npm be added back? Thanks, Matt - Forwarded by Matt Rutkowski/Austin/IBM on 07/09/2019 01:46 PM - From: "David P Grove" To: "OpenWhisk Dev" Date: 07/09/2019 08:10 AM Subject:[EXTERNAL] website build broken The Jenkins job to rebuild the openwhisk website on commits to incubator-openwhisk-website is broken (succeeded on 6/14, next build on 7/3 failed as did a build today). It looks like a change in the Jenkins build environment. The script is not able to find npm [1]. Did we break this when attempting to do the other updates to our worker nodes? + npm install /home/jenkins/jenkins-slave/workspace/OpenWhisk-website@tmp/durable-c5656c4f/script.sh: line 16: npm: command not found [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_O_view_OpenWhisk_job_OpenWhisk-2Dwebsite_237_console=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=ZKLz58mIn2zpsvWZbrrzeSIdKrAZ0G-jmlP0PUpB3Q4=eyw9S7AgkN_zJhPf5ynyHAs2J5FMpvGqa3ndNeH6Y3A=
Re: Re: Re: Re: rationale for wskdeploy Docker image
Agree... the ow-utils should have wskdeploy as long as it can be independently From: "David P Grove" To: dev@openwhisk.apache.org Date: 07/09/2019 12:59 PM Subject:[EXTERNAL] Re: Re: Re: rationale for wskdeploy Docker image "Matt Rutkowski" wrote on 07/09/2019 01:32:22 PM: > > FWIW, I think server-side wskdeploy > usage is a great feature with lots of potential and then having the > convenience binary avail (that matches the wskdeploy client version) may > have value. > Thanks Matt, the use case makes sense. It seems like going forward the use case could be covered by the ow-utils image in the name of image consolidation? We put the wsk cli into ow-utils and wskdeploy functionality is now available via the `wsk project` subcommands. Is that enough? --dave
Re: Re: rationale for wskdeploy Docker image
Previously, when weighing the merging of wskdeploy into CLI, it seemed that the CLI was a good "base" for CRUD operations (commands) against the OW primitives... and that indeed wskdeploy was a great "plug-in" bringing in higher order concepts (some of which are not official OW primitives). In addition, and as a result of the added complexity, the wskdeploy codebase is quite large and fear that it would both increase the complexity of maintaining the CLI, as well as reduce experimentation (e.g., perhaps towards leveraging other deployment targets like knative and bringing in source-to-image pipelines like Jib/Tekton). Still fall on the side of keeping the CLI simple and CRUD based around our existing primitives, but deserves continued discussion over time. -Matt > > From: Rodric Rabbah > To: dev@openwhisk.apache.org > Date: 07/09/2019 03:13 AM > Subject:[EXTERNAL] Re: rationale for wskdeploy Docker image > > > > I think we don’t need it but defer to those who worked on it. > > I’d like to also ask at the risk of broadening the original question: > > - should we fold the repository into the cli? > - or is there a good reason to keep it as a separate deploy tool > independent of the cli? > > -r > > > On Jul 3, 2019, at 4:23 PM, David P Grove wrote: > > > > > > Do we really need to be publishing a wskdeploy image to dockerhub? > > > > I'm not understanding why this image needs to be public (it appears to > > perhaps be an image for building wskdeploy?). > > > > thanks, > > > > --dave > > > > > > > >
Re: Re: rationale for wskdeploy Docker image
I too questioned the "wskdeploy" image (need) during my review, but assumed someone (likely in IBM but perhaps elsewhere as well) may still be using it for server-side deployment; that is, they utilize the image from the https://github.com/apache/incubator-openwhisk-package-deploy project (which indicates it is hardcoded to an old iamge tag, but users likely ref. "latest"). However, when I reached out to a logical contact who worked on this functionality within IBM, she indicated that she was not aware if this image was being actively used/referenced any longer (although I suspect it is). Was hoping Mark Deuser would comment if this is being used by IBM to deploy packages server-side any longer. It is my belief something will break somewhere for some user, but until (if) package-deploy becomes a released repo. (which perhaps may morph the discussion) and no one steps up ... FWIW, I think server-side wskdeploy usage is a great feature with lots of potential and then having the convenience binary avail (that matches the wskdeploy client version) may have value. -Matt From: Rodric Rabbah To: dev@openwhisk.apache.org Date: 07/09/2019 03:13 AM Subject:[EXTERNAL] Re: rationale for wskdeploy Docker image I think we don’t need it but defer to those who worked on it. I’d like to also ask at the risk of broadening the original question: - should we fold the repository into the cli? - or is there a good reason to keep it as a separate deploy tool independent of the cli? -r > On Jul 3, 2019, at 4:23 PM, David P Grove wrote: > > > Do we really need to be publishing a wskdeploy image to dockerhub? > > I'm not understanding why this image needs to be public (it appears to > perhaps be an image for building wskdeploy?). > > thanks, > > --dave >
Re: Re: Re: A plan to (re) implement OpenWhisk on top of Knative
FYI, Priti and I spoke earlier this week about exploring the addition of new "build" command for wskdeploy that could utilize Tekton. Kind regards, Matt From: "Michele Sciabarra" To: dev@openwhisk.apache.org Date: 07/03/2019 12:06 PM Subject:[EXTERNAL] Re: Re: A plan to (re) implement OpenWhisk on top of Knative Well it is actually a bit more complex than this. If we use Tekton for building, it is Tekton the standard, so as long as we define a standard for input and output, we delegate to a tekton build the preparation of an image ready for being served by Knative Serving, However the action loop based runtimes rely on a "compilation" script already written in python that performs the steps, so all I need to do is to adapt the compilation to the Tekton standard. This is something I already did, at lest for Go, modifying the actionloop codee and I am now trying to complete the pipeline. The way I did for Go was not getting rid of the "init" step but providing an "autoinit" step that happens at runtime start, executing a binary executable already embedded in the image and produced by the compilation done by the runtime itself. All of this is more complex to say than to do so I hope I can show something soon... hopefully pretty interesting. --- Michele Sciabarra mich...@sciabarra.com PS the book "learning Apache OpenWhisk" is now on printing! - Original message - From: Matt Rutkowski To: dev@openwhisk.apache.org Subject: Re: Re: A plan to (re) implement OpenWhisk on top of Knative Date: Wednesday, July 03, 2019 4:43 PM Hi Martin, It is my belief that Michele, now freshly returned from book editing (congrats), was going to implement the same interface for pre/post processing requests that we implemented for NodeJS. This would allow us a path to support this across all language runtimes as well as formalize our runtime contract that aligns with a Knative Service approach and then also allows us to better explore some of the use cases being discussed on another thread from Rodric. I believe that we should look at smaller steps towards that alignment like removing the need for the "init" entrypoint and allowing access to parameters either by env. vars. or function arguments allowing both compat. with 12-factor app approach, as well as attempting to encourage a functional programming model where you should ideally be unaware of any system environment. Kind regards, Matt From: Martin Henke To: dev@openwhisk.apache.org Date: 07/03/2019 09:29 AM Subject:[EXTERNAL] Re: A plan to (re) implement OpenWhisk on top of Knative Michele, FYI: Sugandha and myself published a Medium blog article which describes to build Nodejs10 images using Tekton and run it on Knative (based on the work from Priti). It might be on interest in the context of your Actionloop related Knative work. Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__medium.com_-40sugandha.agrawal18_build-2Dknative-2Dservice-2Dwith-2Dtekton-2Dand-2Dapache-2Dopenwhisk-2Dnode-2Djs-2Druntime-2Df660bbc3a11e=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=bl7bwPaoiSE6fi0fyVHNC9bNUnh1ZUUlfl3lwUZbcH0=IQBGPfSTPiAjKhIlsqKDpAjoJBNd7By1YnjxOIx2454= Regards, Martin On 2019/05/20 15:00:02, "Michele Sciabarra" wrote: > Ok great, I see the discussion is starting to bring ideas.> > > Yes my goal is basically to run existing actions in Knative, create and invoke. And possibile retain the ability of an action to invoke another action.> > > I understand the different way they expose services, so I am rethinking the idea of using a "work-alike" path. > > > If it is needed we can add it with an ingress but it may be not necessary in the initial implementation.> > > Also I checked a bit ML and discussions and I see this Tekton thing that should be the preferred way.> > > Not sure if I understand the relation with the current Build API documented in the website. Is Tekton "compatible" or it has a different API?> > > > -- > > Michele Sciabarra> > mich...@sciabarra.com> > > - Original message -> > From: "Markus Thömmes" > > To: dev@openwhisk.apache.org> > Subject: Re: A plan to (re) implement OpenWhisk on top of Knative> > Date: Monday, May 20, 2019 4:50 PM> > > Good discussion, thanks!> > > Can we try to define what the desired end-goal is here? I'm a bit unclear> > what resembling the OpenWhisk API actually buys us.> > > To me, the desired end-state would be to run OpenWhisk actions as-is on a> > Knative cluster (similar to OpenFaaS' and Azure's integration). There's no> > good way for us to provide the full API without
Re: Re: A plan to (re) implement OpenWhisk on top of Knative
Hi Martin, It is my belief that Michele, now freshly returned from book editing (congrats), was going to implement the same interface for pre/post processing requests that we implemented for NodeJS. This would allow us a path to support this across all language runtimes as well as formalize our runtime contract that aligns with a Knative Service approach and then also allows us to better explore some of the use cases being discussed on another thread from Rodric. I believe that we should look at smaller steps towards that alignment like removing the need for the "init" entrypoint and allowing access to parameters either by env. vars. or function arguments allowing both compat. with 12-factor app approach, as well as attempting to encourage a functional programming model where you should ideally be unaware of any system environment. Kind regards, Matt From: Martin Henke To: dev@openwhisk.apache.org Date: 07/03/2019 09:29 AM Subject:[EXTERNAL] Re: A plan to (re) implement OpenWhisk on top of Knative Michele, FYI: Sugandha and myself published a Medium blog article which describes to build Nodejs10 images using Tekton and run it on Knative (based on the work from Priti). It might be on interest in the context of your Actionloop related Knative work. Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__medium.com_-40sugandha.agrawal18_build-2Dknative-2Dservice-2Dwith-2Dtekton-2Dand-2Dapache-2Dopenwhisk-2Dnode-2Djs-2Druntime-2Df660bbc3a11e=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=bl7bwPaoiSE6fi0fyVHNC9bNUnh1ZUUlfl3lwUZbcH0=IQBGPfSTPiAjKhIlsqKDpAjoJBNd7By1YnjxOIx2454= Regards, Martin On 2019/05/20 15:00:02, "Michele Sciabarra" wrote: > Ok great, I see the discussion is starting to bring ideas.> > > Yes my goal is basically to run existing actions in Knative, create and invoke. And possibile retain the ability of an action to invoke another action.> > > I understand the different way they expose services, so I am rethinking the idea of using a "work-alike" path. > > > If it is needed we can add it with an ingress but it may be not necessary in the initial implementation.> > > Also I checked a bit ML and discussions and I see this Tekton thing that should be the preferred way.> > > Not sure if I understand the relation with the current Build API documented in the website. Is Tekton "compatible" or it has a different API?> > > > -- > > Michele Sciabarra> > mich...@sciabarra.com> > > - Original message -> > From: "Markus Thömmes" > > To: dev@openwhisk.apache.org> > Subject: Re: A plan to (re) implement OpenWhisk on top of Knative> > Date: Monday, May 20, 2019 4:50 PM> > > Good discussion, thanks!> > > Can we try to define what the desired end-goal is here? I'm a bit unclear> > what resembling the OpenWhisk API actually buys us.> > > To me, the desired end-state would be to run OpenWhisk actions as-is on a> > Knative cluster (similar to OpenFaaS' and Azure's integration). There's no> > good way for us to provide the full API without spinning up a control plane> > and we can only handle so much via the CLI. So to me, the end-goal looks> > like:> > > 1. *wsk action create* actually doing all the pieces necessary to run a> > piece of code on Knative.> > 2. *wsk action invoke* doing some HTTP call under the hood to "invoke" that> > action. The action should be reachable via a sensible URL. If we really> > want to keep the API surface (as I said, I'm dubious here) we can also do> > that via ingress level abstractions (like VirtualService).> > > Cheers,> > Markus> > > Am Mo., 20. Mai 2019 um 15:33 Uhr schrieb Martin Henke > >:> > > >> > > > On 20. May 2019, at 14:55, Michele Sciabarra > > > wrote:> > > >> > > >> Michele,> > > >> > > >> I like the idea to make the ActionLoop based runtimes to be runnable on> > > Knative.> > > >>> > > >> My thoughts on this:> > > >> - I second Markus concern to implement the invocation API onto Knative> > > instead of just using Knative service syntax.> > > > Can you elaborate this? I do not understand.> > >> > > Knative service syntax:https:// > > action)>../> > > OW invocation https://> > > /api/v1/namespaces//actions/> > >> > > (I personally so no worth in inventing a distinct API for OW images, but> > > as said I would see that as a valid optional feature)> > >> > > >> > > >> - I would have concerns to make it dependent on Gloo which is kind of a> > > minority choice for Knative load balancing> > > > I do not think it will be hard to setup a test also using Istio, I do> > > not want to be limited to Gloo.> > >> > > I just wanted to prevent that Gloo gets a “official” prerequisite for an> > > “official” OW on Knative flow.> > > It is of course free to you to use what ever you want to do in your> > > prototype.> > >> > > > - In my opinion the goal should be to have some uniform
Re: Re: automated builds of all runtimes now publishing using `nightly`
Dave, You're the best! Kind regards, Matt From: Matt Sicker To: dev@openwhisk.apache.org Date: 07/01/2019 04:40 PM Subject:[EXTERNAL] Re: automated builds of all runtimes now publishing using `nightly` Fantastic, thanks for handling this! On Sun, 30 Jun 2019 at 06:19, David P Grove wrote: > > > > The travis setup for all the runtime repos has been changed to use the > nightly tag to indicate the most recent build from the master branch. > > I've submitted a PR to update runtimes.json for core repo's master branch > accordingly [1]. > > My plan is that 48 hours after [1] merges, I will go through all the > runtime images on dockerhub and change the latest tag to refer to the image > that was built from the last official release (1.13.0-incubating). In some > cases (due to image naming convention changes after the 1.13.0-incubating > release), there is no such tag. I believe in most (all?) cases I can > simply do some docker operations to publish the appropriate version of the > old-style name image under the new-style name with the 1.13.0-incubating > tag. > > --dave > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_pull_4529=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=TCGf8zwqExer_aEt3hJd5e7UakbpZJQQA9PtUUQUvJE=3tnNo1L-7l8N4K9bgs2_7UDDwblXOYJiEchLZMxO5uQ= -- Matt Sicker
Re: Re: [DISCUSS] Final draft of project Charter and graduation Resolution
Thanks Matt! will lower-case these names From: Matt Sicker To: dev@openwhisk.apache.org Date: 06/27/2019 12:03 PM Subject:[EXTERNAL] Re: [DISCUSS] Final draft of project Charter and graduation Resolution "Serverless" and "Function" should probably be lowercase. Otherwise looks good! On Thu, 27 Jun 2019 at 10:40, Matt Rutkowski wrote: > > Given the feedback from previous threads both public and private on this Resolution topic, including input from mentors, and the recent apparent confirmation of Dave Grove as proposed VP/Chair for a future PMC being the sole remaining nominee, I have updated the Wiki to represent the final draft of the Resolution we would send to the IPMC general list for their review and subsequent VOTE there. > > Please comment on this thread (and/or Wiki draft page) if anyone has any changes we should make before sending to the IPMC. > > draft link: https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D115526932=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=ZQBkKB7zo_vGmDlUZErkVAN7fKIhSewZK69cwJIMMgA=zV4f-mlnNwWjoyd02LE8VS-HnZwo3LQ94jBSAoBF3lo= > > thx, > mr -- Matt Sicker
Re: Cleaning up old images on Docker Hub, help confirming candidates
No problem leaving the older Ballerina image and can revisit once the language itself hits 1.0 or greater release. On 2019/06/26 08:00:41, Rodric Rabbah wrote: > For the demos, the asciiart image might be from Nick M but I think we can > extract the source into a repo from just the docker image. The spell checker > I may have the source for. It’s a bash script which was covered in a blog > post. > > Do you want to save the sources? We can make them demos under the docker > runtime repo, if so. > > For ballerina I would leave it. 1.0 is slated for release soon and I’ll pick > that up and update the runtime image. > > -r > > > On Jun 25, 2019, at 3:40 PM, Matt Rutkowski wrote: > > > > Just made a pass through all images under the "openwhisk" moniker on Docker > > Hub: > > https://hub.docker.com/u/openwhisk/ > > > > assuring all have valid (short) descriptions and long descriptions that > > clearly describe each belonging to our Apache project proper (adapting 2 > > examples from other Apache projects, thanks Rodric). In addition, we > > BOLDly indicate these are convenience binaries and point back to the our > > Apache repos. in github where they are generated from as build artifacts. > > > > Along the way, I found the following images that I believe should be > > deprecated (i.e., deleted from Docker Hub) along with my notes as to when > > they stopped being used/generated and last build date: > > > > -- > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-ballerina-v0.975 > > (5 months, current version action-ballerina-v0.990.2), same major version, > > not sure who is maintaining > > > > --- > > replaced by ow-utils: > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/ansible-runner > > (7 months, replaced bu ow-utils image > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/script-runner > > (7 months, replaced bu ow-utils image) > >* deprecated by this PR: > > https://github.com/apache/incubator-openwhisk/pull/4158 > > > > > > > > Kube related: > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-ansible-runner > > (10 months, replaced by ansible-runner) > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-script-runner > > (10 months, replaced by script-runner) > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-kafkapkginstaller > > (1 year+) > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-routemgmt > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-openwhisk-catalog > >* deprecated by these PRs > >* https://github.com/apache/incubator-openwhisk-deploy-kube/pull/239 > > (Kubernetes YAML removed) > >* https://github.com/apache/incubator-openwhisk-deploy-kube/pull/249 > > (Dockerfile removed) > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-couchdb > >* deprecated by these PRs > >* https://github.com/apache/incubator-openwhisk-deploy-kube/pull/239 > > (Kubernetes YAML removed) > >* https://github.com/apache/incubator-openwhisk-deploy-kube/pull/261 > > (uses ow-utils and initdb.sh script to run ansible playbooks in main OW) > > > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-docker-pull > > (now uses ow-utils as part of “helpers”) > > * deprecated by these PRs: > >* https://github.com/apache/incubator-openwhisk-deploy-kube/pull/249 > >* https://github.com/apache/incubator-openwhisk-deploy-kube/pull/209 > > > > - > > Not sure of the history of Swift, but it appears that some of these images > > were early (dev.,test) attempts at publishing to DockerHub: > > > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-swift-v4.0 > > (1 year+) > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-swift-v4 > > (1 year+) > > - > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/swift3action > > (2+ years ago) > > - > > > > Early
Re: Cleaning up old images on Docker Hub, help confirming candidates
Carlos, >From the list, to my knowledge, none of these are actively used for current >Travis/Jenkins... do any jump out as you as ones we could not deprecate >(effectively delete)? Mainly concerned over the aberrant Swift ones that look >like early "one offs" which you may have insight on? thx, matt On 2019/06/26 10:06:01, Carlos Santana wrote: > I think the images being actively used by Travis or jenkins testing should > remain in the current repository their current usage should be as nightly > builds only intended for dev and build integrating testing. > > I think having the tag latest is not a big deal as it’s a default tag when > pulling containers, but I’m not going to oppose if someone wants to change it > to something like “dev” or like I had at one point “master” which then Rodric > changes to “latest” :-) > > As for the convenient binaries of the release, I think these images should be > build out of Apache jenkins server using the source code that is already > released on the “dist” directory from Apache distribution server these images > should not be in the current “openwhisk” docker namespace they should be > pushed to the Apache “docker.io/apache/incubator-openwhisk-*:version” [1] > We also need to check what are the ASF Infra requirements to host an image > under the Apache namespace like the requirement to secure the image by > signing the image or just have the digest/taghash documented for > verification. > > [1] https://hub.docker.com/u/apache > > - Carlos Santana > @csantanapr > > > On Jun 26, 2019, at 4:00 AM, Rodric Rabbah wrote: > > > > For the demos, the asciiart image might be from Nick M but I think we can > > extract the source into a repo from just the docker image. The spell > > checker I may have the source for. It’s a bash script which was covered in > > a blog post. > > > > Do you want to save the sources? We can make them demos under the docker > > runtime repo, if so. > > > > For ballerina I would leave it. 1.0 is slated for release soon and I’ll > > pick that up and update the runtime image. > > > > -r > > > >> On Jun 25, 2019, at 3:40 PM, Matt Rutkowski wrote: > >> > >> Just made a pass through all images under the "openwhisk" moniker on > >> Docker Hub: > >> https://hub.docker.com/u/openwhisk/ > >> > >> assuring all have valid (short) descriptions and long descriptions that > >> clearly describe each belonging to our Apache project proper (adapting 2 > >> examples from other Apache projects, thanks Rodric). In addition, we > >> BOLDly indicate these are convenience binaries and point back to the our > >> Apache repos. in github where they are generated from as build artifacts. > >> > >> Along the way, I found the following images that I believe should be > >> deprecated (i.e., deleted from Docker Hub) along with my notes as to when > >> they stopped being used/generated and last build date: > >> > >> -- > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-ballerina-v0.975 > >> (5 months, current version action-ballerina-v0.990.2), same major > >> version, not sure who is maintaining > >> > >> --- > >> replaced by ow-utils: > >> > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/ansible-runner > >> (7 months, replaced bu ow-utils image > >> > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/script-runner > >> (7 months, replaced bu ow-utils image) > >> * deprecated by this PR: > >> https://github.com/apache/incubator-openwhisk/pull/4158 > >> > >> > >> > >> Kube related: > >> > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-ansible-runner > >> (10 months, replaced by ansible-runner) > >> > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-script-runner > >> (10 months, replaced by script-runner) > >> > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-kafkapkginstaller > >> (1 year+) > >> - > >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-routemgmt > >> - > >> https://cloud.docker.com/u/ope
[DISCUSS] Final draft of project Charter and graduation Resolution
Given the feedback from previous threads both public and private on this Resolution topic, including input from mentors, and the recent apparent confirmation of Dave Grove as proposed VP/Chair for a future PMC being the sole remaining nominee, I have updated the Wiki to represent the final draft of the Resolution we would send to the IPMC general list for their review and subsequent VOTE there. Please comment on this thread (and/or Wiki draft page) if anyone has any changes we should make before sending to the IPMC. draft link: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 thx, mr
Notes & Video posted from today's Tech Int. call
Notes: https://cwiki.apache.org/confluence/display/OPENWHISK/2019-06-26+OW+Tech+Interchange+-+Meeting+Notes Video: https://youtu.be/HkIzJXlTw68 Thanks Rodric for hosting... Matt is up next call for July 10th iteration.
Re: exporting activation arguments to the environment
Hi Rodric, Have many thoughts on this having just experienced them all when mapping our OW "runtime contract" to Knative... but first would ask a couple of things based on your historic knowledge... M1) Do you have a specific use case which highlights the issue (i.e., caused you to think on this at this time)? M2) what was the intent of the separation of between init and run (esp. as it seems other impl.s of Serverless like Knative are moving to single exported entrypoint). Will there ever be a "re-init" to reuse a runtime (framework). Will we explore a V8 Isolates approach? 3M) It seems knative thinking is 12-factor app... everything in ENV of container whereas, as a functions (as a workload) developer would hopefully attempt to perform their task without any environmental (OS) awareness ans strictly remain within the function scope. Should we not seek to re-enforce the Serverless differentiation? or give into the notion that functions are just "baked into" Containers. After our knative work, I was actually thinking that init and run distinction should go away as init serves little purpose... that we should endeavor to have a unified container proxy that was a single point enforcement/data massaging for all runtimes (seemingly moving in this direction naturally anyways). Then use the container proxy to explore new use cases uniformly (e.g., other protocols, etc.).
Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution
This PMC Chair nominations thread is closed. Will reach out to both Dave and Rodric, as both appeared to defer to each other, to see if either wants to step back and perhaps we can reduce the need for a competitive VOTE (and have just an affirmation VOTE as this may be asked for) and move onto seeing if we want to create a yearly nomination/rotation system where either Dave or Rodric serve for the first year... Thanks everyone for participating. -Matt > > This thread is intended to solicit nominations (self or on-behalf of another) > to begin the process of selecting a candidate for election (i.e., via a > subsequent vote thread) to this position. This thread will be kept open > until Tuesday at 1PM US EDT which is one week from now (and greater than the > 72-hour required min. for any VOTE). > > After all nominations are accounted for, and after the nominees acknowledge > their interest in fulfilling the role of PMC Chair, we can then discuss the > process of holding an official vote. > > I encourage anyone interested in leading the project forward, regardless of > current status or contribution area, to express their intentions here knowing > that you will have the support of our amazing Community and PMC who are full > of excitement around embracing new technologies and potential integrations. >
Cleaning up old images on Docker Hub, help confirming candidates
Just made a pass through all images under the "openwhisk" moniker on Docker Hub: https://hub.docker.com/u/openwhisk/ assuring all have valid (short) descriptions and long descriptions that clearly describe each belonging to our Apache project proper (adapting 2 examples from other Apache projects, thanks Rodric). In addition, we BOLDly indicate these are convenience binaries and point back to the our Apache repos. in github where they are generated from as build artifacts. Along the way, I found the following images that I believe should be deprecated (i.e., deleted from Docker Hub) along with my notes as to when they stopped being used/generated and last build date: -- - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-ballerina-v0.975 (5 months, current version action-ballerina-v0.990.2), same major version, not sure who is maintaining --- replaced by ow-utils: - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/ansible-runner (7 months, replaced bu ow-utils image - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/script-runner (7 months, replaced bu ow-utils image) * deprecated by this PR: https://github.com/apache/incubator-openwhisk/pull/4158 Kube related: - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-ansible-runner (10 months, replaced by ansible-runner) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-script-runner (10 months, replaced by script-runner) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-kafkapkginstaller (1 year+) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-routemgmt - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-openwhisk-catalog * deprecated by these PRs * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/239 (Kubernetes YAML removed) * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/249 (Dockerfile removed) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-couchdb * deprecated by these PRs * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/239 (Kubernetes YAML removed) * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/261 (uses ow-utils and initdb.sh script to run ansible playbooks in main OW) https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-docker-pull (now uses ow-utils as part of “helpers”) * deprecated by these PRs: * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/249 * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/209 - Not sure of the history of Swift, but it appears that some of these images were early (dev.,test) attempts at publishing to DockerHub: - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-swift-v4.0 (1 year+) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-swift-v4 (1 year+) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/swift3action (2+ years ago) - Early dev/test images? - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/couchdb-snapshot (2+ years ago) - https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/couchdb-catalog (2+ years ago) - Also, found these old Docker SDK samples/demos? which would love to know where the source code exists for the actual code to see if we want to use as our own examples and automate builds for (perhaps as part of the SDK). Note: * they referenced bluemix home page… REMOVED * with the quote "This image demonstrates OpenWhisk's support for executing arbitrary code in a safe manner. Bring your own docker image.”. * Single tag “latest” (single push) https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/javaaction (2+ years ago) * No description https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/thumbnail (3+ years ago) * A example docker image that creates a polaroid-style thumbnail from a given image URL. https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/asciiart (3+ years ago) * A example docker image that creates a polaroid-style thumbnail from a given image URL. https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/spellcheck (3+ years ago) * A example docker image that includes a spell client that interfaces with aspell. (sic) Please comment if these can/should be deleted or if not please let us know why and how we proceed to make current. Thanks, Matt
Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution
PS Please know that I do not intend to make any nominations (self or otherwise). Kind regards, Matt
[ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution
As part of the graduation process as a top-level project, we must craft a draft resolution which includes the naming of a PMC Chair for the project. Please see discussion and actual draft using these links: * dev list:https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=115526933=c5ef8b7b-f542-47c1-a435-cf5b94921fbb; * draft resolution (Cwiki): https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 This thread is intended to solicit nominations (self or on-behalf of another) to begin the process of selecting a candidate for election (i.e., via a subsequent vote thread) to this position. This thread will be kept open until Tuesday at 1PM US EDT which is one week from now (and greater than the 72-hour required min. for any VOTE). After all nominations are accounted for, and after the nominees acknowledge their interest in fulfilling the role of PMC Chair, we can then discuss the process of holding an official vote. I encourage anyone interested in leading the project forward, regardless of current status or contribution area, to express their intentions here knowing that you will have the support of our amazing Community and PMC who are full of excitement around embracing new technologies and potential integrations.
Notes and Video posted from today's Tech. Int. call
Thanks Vincent for moderating. Video: https://youtu.be/BYiEErT_W3I Notes: https://cwiki.apache.org/confluence/display/OPENWHISK/2019-06-12+OW+Tech+Interchange+-+Meeting+Notes James volunteered to host next call. Cheers, Matt
Re: managing our project trademarks
Rodric, Great reference and agree with Bertrand that we should copy Spark's stellar example. To that end, please review PR which accomplishes that goal: https://github.com/apache/incubator-openwhisk-website/pull/387/files Thanks, Matt On 2019/06/12 11:15:51, Rodric Rabbah wrote: > The discussion about our graduation on the general list [1] led to a > question relating to how we manage the project trademarks. Specifically, > our project website does not provide any guidance we can point to when > needed. We have previously discussed the use of the OpenWhisk name in a > prior instance [2] but did not document our guidance on the website. Apache > Spark is one example that might be useful for reference, available at > http://spark.apache.org/trademarks.html. It provides appropriate links to > the ASF [3] and summarizes the key points of the policy. > > This email is to solicit help authoring our own project trademarks policy > summary page, and to solicit feedback on additional points to summarize > relating to the use of the name OpenWhisk. > > For example, how do we handle the use of OpenWhisk in a GitHub repository > name? A small sample of searches on popular Apache project names leads one > to believe this is quite common. In some cases it may be sufficient for > the repository to use the full project name "Apache OpenWhisk" prominently > in the project description and first mentions in the documentation (with > links to the project website). When do we require an acknowledgement of the > trademark, or ask a repository to be renamed? > > -r > > [1] > https://lists.apache.org/thread.html/02dd71dcc6b2f326015954388c61d06d12f982fd64f34ee40e076171@%3Cgeneral.incubator.apache.org%3E > > [2] > https://lists.apache.org/thread.html/99e2431472d015fb23af38d1c2dab47ef9eb5a8a980cf2b80ca0035b@%3Cdev.openwhisk.apache.org%3E > > [3] https://www.apache.org/foundation/marks/faq/#products >
Re: LICENSE file in repo
Legacy copy/paste... Fixed in PR https://github.com/apache/incubator-openwhisk-website/pull/386 Kind regards, Matt From: Craig Russell To: dev@openwhisk.apache.org Date: 06/07/2019 06:43 PM Subject:[EXTERNAL] LICENSE file in repo Hi, Just noticed this LICENSE file https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dwebsite_blob_master_LICENSE.txt=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=fSDOBGP9ptnIL3vtV8YPja_cau0MXl4el7c7khaci60=NlPK71mHxz5OIFUhCiQHZXf8EXk7d6UWVOY7uUrbT_Q= that contains "Copyright 2015-2017 IBM Corporation". Surely this is a copy/paste error. Craig Craig L Russell c...@apache.org
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
Excellent! [X] +1 Apache OpenWhisk should graduate. [ ] +0 No opinion [ ] -1 Apache OpenWhisk should not graduate (please provide the reason) Matt Rutkowski
Re: Help answering last few Project Maturity Model Qs for graduation readiness
Thanks for the responses here which have been very helpful. I have endeavored to include all responses (represent in some way the heart of) in updating the corresponding table rows. Please let me know what you think of the results. On 2019/05/15 18:32:27, Matt Rutkowski wrote: > Hello Whiskers! > You may not have noticed, but last month I endeavored to complete filling out > our project maturity model which has been an ongoing process for a since last > fall (at least). For reference, it is located on our project Wiki here: > > https://cwiki.apache.org/confluence/display/OPENWHISK/Project+Maturity+Model > > Last month, when I came upon the last 2 sections titled "Consensus Building" > and "Independence" (especially), I found it hard to complete using just my > viewpoint which I consider biased (and of course from IBM which helped > charter the project). I would like to use this thread to raise the questions > from that section and ask that our community help supply their honest > answers/opinions. Including: > > - Here are the questions: > > **Consensus building** > [CS50] *All "important" discussions happen asynchronously in written form on > the project's main communications channel. Offline, face-to-face or private > discussions 11 that affect the project are also documented on that channel.* > > **Independence** > [IN10] *The project is independent from any corporate or organizational > influence.* > [IN20] *Contributors act as themselves as opposed to representatives of a > corporation or organization.* > > - > > Of course, feel free to comment on the Wiki as well. I would love to have > enough responses to propose the final text by middle of next week. Please > help with any contributions to the answers. > > Thanks, > Matt > >
Re: [REVIEW] draft proposal for TLP project charter and ASF board resolution
On 2019/05/29 19:05:37, Matt Rutkowski wrote: > Dear Whiskers, > > As a community we have been discussing the possibility of graduation for > quite some time. In the wake of the last legal hurdle being cleared (i.e., > IBM completed transfer of all trademarks and name registrations to the ASF > board) and in anticipation of a VOTE thread, I have created a page on our > CWiki for drafting 2 artifacts we would need to present to the board as part > of the process, that is the graduated project Charter (simple, > straightforward) and the Resolution (which references the charter/project > scope) to become a Top-Level-Project (TLP). > > I am asking you all, as you did for the Maturity model review, to please help > develop/review/comment on these items as well: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 > > Note that some background and links that describe the process and artifacts > are included on the page as well. > > FYI, I brought this up as a topic on the agenda of today's Tech. Int. call if > you want my unedited "take" on the process and these items: > https://www.youtube.com/watch?v=kxxTLBC1QD8 > > Thanks for your help! > -Matt > Please check out the charter (simple sentence derived from our CWiki tag line) on proposal page and let me know if we should amend it in any way My Qs... do I need to say FaaS to qualify Serverless? should we say anything about supporting Cloud Native (i.e., 12-factors implied, portable to any Container framework)?
Re: Re: Incubator status report
Hi Bertrand, You should now have edit access to the Wiki, -mr From: Bertrand Delacretaz To: OpenWhisk Dev Date: 06/03/2019 09:35 AM Subject:[EXTERNAL] Re: Incubator status report On Mon, Jun 3, 2019 at 12:13 AM Matt Sicker wrote: > ...I can't seem to edit the wiki page, so you can add a signoff from me... I also cannot edit https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D115527317=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=cs_aXTxO3BWJAdgrv1VKS1Ju6lvp_niu9LslcgcJC5c=dKE_roXuNJ31pfgNAyKtea11W-fwaXlvmPZM2IK2QEY= although editing https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_INCUBATOR_June2019=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=cs_aXTxO3BWJAdgrv1VKS1Ju6lvp_niu9LslcgcJC5c=OagAhBgCW1YzDQlPPSOTUdHj0jxWZ007xO7F8zZgU_A= for example works. Feel free to add my signoff to the draft report. AFAIK cwiki.apache.org is now backed by the ASF LDAP services, so maybe someone needs to change the permissions to allow all OpenWhisk PMC members to edit (+contributors who ask for that). -Bertrand
Re: Re: PPMC subscription to this list
Hi Dominic, If you followed the steps on our project Wiki here (home page) under the " Becoming a Podling Project Management Committee (PPMC) Member" section, then you should be fine. https://cwiki.apache.org/confluence/display/OPENWHISK/OpenWhisk+Project+Wiki Kind regards, Matt From: Dominic Kim To: dev@openwhisk.apache.org Date: 06/02/2019 04:54 PM Subject:[EXTERNAL] Re: PPMC subscription to this list Oh, I thought this is a thread from the private mailing list but it was `dev` mailing list.. Dominic. 2019년 6월 3일 (월) 오전 6:45, Dominic Kim 님이 작성: > It might be silly. > But can I safely assume that I signed up for the private if I am receiving > this email? > > Best regards > Dominic > > 2019년 6월 3일 (월) 오전 2:59, Matt Rutkowski 님이 작성: > >> Hi Justin, >> >> Ironically, we are in the process of cleaning up our PPMC list (including >> removal of those who have never signed up for private) within the PPMC >> private list. >> >> Kind regards, >> Matt Rutkowski >> >> >> >> >> >> >> From: Justin Mclean >> To: >> Date: 06/01/2019 08:11 PM >> Subject:[EXTERNAL] PPMC subscription to this list >> >> >> >> Hi, >> >> Several of your PPMC members are not signed up to this private list. It's >> a requirement that all PPMC and member sign up to this list so they that >> can vote on new committers or PPMC members, and respond to security >> issues. It would be great if you can fix this. >> >> Thanks, >> Justin >> >> >> >> >> >>
Re: PPMC subscription to this list
Hi Justin, Ironically, we are in the process of cleaning up our PPMC list (including removal of those who have never signed up for private) within the PPMC private list. Kind regards, Matt Rutkowski From: Justin Mclean To: Date: 06/01/2019 08:11 PM Subject:[EXTERNAL] PPMC subscription to this list Hi, Several of your PPMC members are not signed up to this private list. It's a requirement that all PPMC and member sign up to this list so they that can vote on new committers or PPMC members, and respond to security issues. It would be great if you can fix this. Thanks, Justin
Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc2)
Please vote to approve this release: [X] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... 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 as specified by OpenWhisk project policy [1]. [X] No compiled archives bundled in source archive. local run: $ ./tools_rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' 0.10.0-incubating rc2 -bash: ./tools_rcverify.sh: Permission denied Matthews-MacBook-Pro-3:verify Matt$ chmod +x tools_rcverify.sh Matthews-MacBook-Pro-3:verify Matt$ ./tools_rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' 0.10.0-incubating rc2 tools_rcverify.sh (script SHA1: 6871 208F 37F8 2352 BA60 E66E 8953 94E8 2832 AA69) working in the following directory: /var/folders/nj/2blqqtm500l5ch2d5k0hvqvmgq/T/tmp.xCszS3Bp fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2 fetching openwhisk-apigateway-0.10.0-incubating-sources.tar.gz fetching openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc fetching openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 fetching release keys importing keys gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) " not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: Total number processed: 3 gpg: unchanged: 3 unpacking tar ball cloning scancode Cloning into 'incubator-openwhisk-utilities'... remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (42/42), done. remote: Total 57 (delta 19), reused 37 (delta 12), pack-reused 0 Unpacking objects: 100% (57/57), done. computing sha512 for openwhisk-apigateway-0.10.0-incubating-sources.tar.gz SHA512: openwhisk-apigateway-0.10.0-incubating-sources.tar.gz: F3A852F8 95982ED3 5735336F D1A85FF6 AE4575AA BAF251A7 0B77AA40 EE4D0727 09C40A99 6F1BD0ED CDA91B9B 59C9C3AF 19E7AC52 BF05A869 61C113D9 D42BB691 validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying disclaimer... passed verifing notice... passed 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 On 2019/05/29 21:50:35, "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] >
Re: [VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc2) apache-openwhisk x
Please vote to approve this release: [X] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... 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. my local verify output: $ ./rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js' 1.14.0-incubating rc2 working in the following directory: /var/folders/nj/2blqqtm500l5ch2d5k0hvqvmgq/T/tmp.Bqy5jqSV fetching openwhisk-runtime-nodejs-1.14.0-incubating-sources.tar.gz fetching openwhisk-runtime-nodejs-1.14.0-incubating-sources.tar.gz.asc fetching openwhisk-runtime-nodejs-1.14.0-incubating-sources.tar.gz.sha512 fetching release keys import keys gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) " not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: Total number processed: 3 gpg: unchanged: 3 unpacking tar ball cloning scancode Cloning into 'incubator-openwhisk-utilities'... remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (42/42), done. remote: Total 57 (delta 19), reused 37 (delta 12), pack-reused 0 Unpacking objects: 100% (57/57), done. computing sha512 and validating... passed verifying asc... passed (signed-by: Vincent Hou (Release manager of OpenWhisk) ) verifying disclaimer... passed verifing notice... passed verifying license... passed verifying sources have proper headers... passed scanning for binaries... passed scanning for archives... passed scanning for packages... passed On 2019/05/30 16:42:35, 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 >
