Re: [VOTE] Release Apache OpenWhisk Package Alarms (v2.3.0, rc1)

[Rodric Rabbah]

+1 to release openwhisk-package-alarms 2.3.0 rc1

Checked with rcverify.

>  ./rcverify.sh openwhisk-package-alarms 2.3.0 rc1
rcverify.sh (script SHA1: 7FC5 5DBE 1809 6D92 DEFF  0E31 D138 059B 8F27
20F7)
working in the following directory:
/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.biVgT6jD
fetching tarball and signatures from
https://dist.apache.org/repos/dist/dev/openwhisk/rc1
fetching openwhisk-package-alarms-2.3.0-sources.tar.gz... ok
fetching openwhisk-package-alarms-2.3.0-sources.tar.gz.asc... ok
fetching openwhisk-package-alarms-2.3.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-package-alarms-2.3.0-sources.tar.gz... ok
openwhisk-package-alarms-2.3.0-sources.tar.gz:
3843170D 6AFEA73A 71591334 7251AE6E 8527553B 0B11C369 0E24BE25 8A88C271
8176846C
 1EC2BC53 35D8F7C1 3B46A9BD 7839F36F 4112D5A8 7B598FA1 552CF4A7
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
scanning package-lock.json for version match... passed (none detected)
removing the scratch space
(/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.biVgT6jD)... ok

On Mon, Aug 23, 2021 at 9:08 AM David P Grove  wrote:

>
>
> Hi,
>
> This is a call to vote on releasing version 2.3.0 release candidate rc1 of
> the following project module with artifacts built from the Git repositories
> and commit IDs listed below.
>
> * OpenWhisk Package Alarms: a5d69be420654b41bef50f1671f314b9e1cd7894
>
>
> https://github.com/apache/openwhisk-package-alarms/commit/a5d69be420654b41bef50f1671f314b9e1cd7894
>
>
> https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-package-alarms-2.3.0-sources.tar.gz
>
>
> https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-package-alarms-2.3.0-sources.tar.gz.asc
>
>
> https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-package-alarms-2.3.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=5ff98d7
>
> Usage:
> curl -s "
>
> https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=5ff98d7
> " -o rcverify.sh
> chmod +x rcverify.sh
> ./rcverify.sh openwhisk-package-alarms 2.3.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
>

[slack-digest] [2021-08-27] #general

[OpenWhisk Team Slack]

2021-08-27 18:02:40 UTC - Brendan Doyle: We'd like to add an api that allows 
updating `invocationsPerMinute` by the user of the namespace through the 
controller. Currently we have to take in a request from a user and then 
manually update it through couchdb for them. In our eyes, 
`invocationsPerMinute` is a user protection for their functions and downstream 
dependencies of their functions; and doesn't actually do anything to protect 
the system deployment. Whereas `concurrentInvocations` is really the throttle 
that protects over provisioning on the system  and needs to be controlled 
through an admin.

Would there be any opposition to such an api or is there something 
theoretically I'm missing on how controlling `invocationsPerMinute` protects 
the system itself and not the user's functions?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1630087360004900?thread_ts=1630087360.004900=C3TPCAQG1