documenting OpenShift/OKD deployment (was CRI-O support)

[David P Grove]

Hi Henry,

I've tried to write up some guidance using your emails on how to
deploy on OS4 using openwhisk-deploy-kube.

The PR is here [1].

I'm sure it is incomplete, so it would be greatly appreciated if you
could help flesh out the PR.  You can either comment or submit PRs against
my fork/branch and I'll merge them in.  Anything that makes it easier for
you to add docs.

thanks,

--dave

[1] https://github.com/apache/incubator-openwhisk-deploy-kube/pull/465



From:   Henry Zektser 
To: Sven Lange-Last ,
dev@openwhisk.apache.org
Date:   05/13/2019 08:50 AM
Subject:Re: CRI-O support?



Hey Sven,
I guess what I’m trying to articulate is that openwhisk-deploy-kube fails
in the case of OpenShift 4.. I wanted to get the groups thoughts and
confirm I’m not missing anything before I try to hammer in CRI-O support —
which appears like it won’t be that easy. Here’s what I’m seeing — in
painful detail — so I apologize for the long dump in advance. This is all
done on a bare-naked OS4 deploy (
https://urldefense.proofpoint.com/v2/url?u=https-3A__try.openshift.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Fe4FicGBU_20P2yihxV-apaNSFb6BSj6AlkptSF2gMk=JQ2OhHrNe2rRbL8Mqbz13ZpzhZgORYrA00cV3bHC4ng=0bvsTVRzU46DOMIgMvhNmwRs4TrUI8ub4Qpy0kfnrws=
) in AWS.

1. Label the worker nodes
oc label node ip-10-0-143-24.us-east-2.compute.internal
openwhisk-role=invoker
oc label node ip-10-0-144-49.us-east-2.compute.internal
openwhisk-role=invoker
oc label node ip-10-0-166-72.us-east-2.compute.internal
openwhisk-role=invoker

2. Because OpenShift doesn’t allow arbitrary UIDs by default, I allow them
explicitly
oc adm policy add-scc-to-user anyuid -z default
oc adm policy add-scc-to-user privileged -z default
oc adm policy add-scc-to-user anyuid -z openwhisk-core
oc adm policy add-scc-to-user privileged -z openwhisk-core

3. From the tip of master for incubator-openwhisk-deploy-kube, I run the
helm chart
helm template ./helm/openwhisk --namespace=openwhisk --name=openwhisk | oc
create -f -

4. Grab coffee while things come up :)

5. Comment out resolver kube-dns.kube-system; in the nginx ConfigMap — this
actually causes a crash loop in OpenShift. Then restart the pod. It comes
up happy.

6. NOTE: This is where the problem lies. The openwhisk-invoker-* pods sit
in initCrashLoopBackOff. The logs for these all show the same thing in the
docker-pull-runtimes container — no docker = ansible failure. The complete
log of the init container is at the bottom of this message.

I’ll confess this new release from RedHat has me re-learning 50% of what I
solidly had a grasp on 2 weeks ago, but I think the net/net is, this
deployment is expecting to connect to the docker socket on the underlying
host. I can see that in the YAML for the pod;
  volumeMounts:
- name: dockersock
  mountPath: /var/run/docker.sock
Given OS4 only runs on RedHat CoreOS now, and doesn’t even deploy docker..
I believe there’s a problem here? I suppose it’s conceivable if I map the
CRI-O socket instead, the docker client might work? I haven’t tried it yet
— I’ve left my deploy bone-stock in case any of the devs would like to see
some additional dumps/debug data/etc before I start messing around with it…
I’m happy to be the guinea pig if anyones got a workaround.. Also happy to
start working on CRI-O support if that’s what we really need here, though
again, not sure that’s going to be easy or quick.


[WARNING]: Unable to parse /etc/ansible/hosts as an inventory source
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note
that the implicit localhost does not match 'all' PLAY [localhost]
*** TASK
[Gathering Facts] *
ok: [localhost] TASK [docker login]
 skipping:
[localhost] TASK [Display runtime manifest]
 ok: [localhost] => {
"runtimes_manifest": { "blackboxes": [ { "name": "dockerskeleton",
"prefix": "openwhisk", "tag": "3d6ee06" } ], "runtimes": { "ballerina": [ {
"attached": { "attachmentName": "codefile", "attachmentType": "text/plain"
}, "default": true, "deprecated": false, "image": { "name":
"action-ballerina-v0.990.2", "prefix": "openwhisk", "tag": "d049638" },
"kind": "ballerina:0.990" } ], "dotnet": [ { "attached": {
"attachmentName": "codefile", "attachmentType": "text/plain" }, "default":
true, "deprecated": false, "image": { "name": "action-dotnet-v2.2",
"prefix": "openwhisk", "tag": "50df3ba" }, "kind": "dotnet:2.2",
"requireMain": true } ], "go": [ { "attached": { "attachmentName":
"codefile", "attachmentType": "text/plain" }, "default": true,
"deprecated": false, "image": { "name": "actionloop-golang-v1.11",
"prefix": "openwhisk", "tag": "ddd3299" }, "kind": "go:1.11" } ], "java": [
{ 

Re: [DISCUSS] - Release apigateway 0.10.0-incubating

[Carlos Santana]

+1

- Carlos Santana
@csantanapr

> On May 17, 2019, at 1:03 PM, David P Grove  wrote:
> 
> 
> I would like to start the release process for the apigateway module on
> Monday.
> 
> I propose using version number 0.10.0-incubating for this release.
> 
> There are currently no open PRs against the repo.  Anything coming soon
> that we should wait for or any known blocking issues for a release?
> 
> thanks,
> 
> --dave

Re: [DISCUSS] - Release apigateway 0.10.0-incubating

[Matt Hamann]

I agree with this proposal. There are currently no blocking issues
around the gateway as far as I am aware.


-Matt
matthew.ham...@gmail.com

On Fri, May 17, 2019 at 1:03 PM David P Grove  wrote:
>
>
> I would like to start the release process for the apigateway module on
> Monday.
>
> I propose using version number 0.10.0-incubating for this release.
>
> There are currently no open PRs against the repo.  Anything coming soon
> that we should wait for or any known blocking issues for a release?
>
> thanks,
>
> --dave

[DISCUSS] - Release apigateway 0.10.0-incubating

[David P Grove]

I would like to start the release process for the apigateway module on
Monday.

I propose using version number 0.10.0-incubating for this release.

There are currently no open PRs against the repo.  Anything coming soon
that we should wait for or any known blocking issues for a release?

thanks,

--dave

Re: [VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)

[Carlos Santana]

I didn’t see a [DISCUSS] thread before this [VOTE] thread

This are the type of things that the board will be looking for graduation 
criteria to see if we follow the establish process in a consistent way with the 
community. 

[DISCUSS] thread allows to get buy in and to see if any one has an issue 
starting to cut an RC of something is almost ready and should be included or 
just wait for the next release, etc..


- Carlos Santana
@csantanapr

> On May 17, 2019, at 12:19 PM, James Thomas  wrote:
> 
> Hello,
> 
> This is a call to vote on releasing version 1.14.0-incubating release
> candidate rc1 of the following project module with artifacts
> built from the Git repositories and commit IDs listed below.
> 
> * Apache OpenWhisk Runtime Node.js:
> 3bf5268https://github.com/apache/incubator-openwhisk-runtime-nodejs.git/commits/3bf5268
> 
> This release is comprised of source code distribution only.
> 
> You can use this UNIX script to download the release and verify the
> checklist 
> below:https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD
> 
> Usage:
> curl -s 
> "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD;
> -o rcverify.sh
> chmod +x rcverify.sh
> rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js'
> 1.14.0-incubating rc1
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> Release verification checklist for reference:
>  [ ] Download links are valid.
>  [ ] Checksums and PGP signatures are valid.
>  [ ] DISCLAIMER is included.
>  [ ] Source code artifacts have correct names matching the current release.
>  [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository.
>  [ ] All files have license headers if necessary.
>  [ ] No compiled archives bundled in source archive.
> 
> This majority vote is open for at least 72 hours.
> 
> 
> -- 
> Regards,
> James Thomas

[VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)

[James Thomas]

Hello,

This is a call to vote on releasing version 1.14.0-incubating release
candidate rc1 of the following project module with artifacts
built from the Git repositories and commit IDs listed below.

* Apache OpenWhisk Runtime Node.js:
3bf5268https://github.com/apache/incubator-openwhisk-runtime-nodejs.git/commits/3bf5268

This release is comprised of source code distribution only.

You can use this UNIX script to download the release and verify the
checklist 
below:https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD

Usage:
curl -s 
"https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD;
-o rcverify.sh
chmod +x rcverify.sh
rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js'
1.14.0-incubating rc1

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

Release verification checklist for reference:
  [ ] Download links are valid.
  [ ] Checksums and PGP signatures are valid.
  [ ] DISCLAIMER is included.
  [ ] Source code artifacts have correct names matching the current release.
  [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository.
  [ ] All files have license headers if necessary.
  [ ] No compiled archives bundled in source archive.

This majority vote is open for at least 72 hours.


-- 
Regards,
James Thomas

[GitHub] [incubator-openwhisk-pluggable-provider] jthomas opened a new issue #2: Trigger manager should return failures for trigger firing

[GitBox]

jthomas opened a new issue #2: Trigger manager should return failures for 
trigger firing
URL: https://github.com/apache/incubator-openwhisk-pluggable-provider/issues/2
 
 
   
https://github.com/apache/incubator-openwhisk-pluggable-provider/blob/master/provider/lib/triggers_manager.js#L202-L240
   
   Provider plugins need to know if triggers have been fired correctly. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[slack-digest] [2019-05-16] #random

[OpenWhisk Team Slack]

2019-05-16 05:40:32 UTC - Jin Choi: One question: I have a web action which 
emits an HTML as the result. The thing is, even if I `curl` it with 
`--compressed` option the HTML comes in the plain text regarding the headers. 
Using Chrome browser as a client doesn't make a change. So, can I have my web 
action's result encoded in gzip in response?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557985232048800

2019-05-16 07:08:03 UTC - Rodric Rabbah: If the action compressed the output 
and base64 encoded it, and sets the proper header, I’d expect it to work.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557990483050700?thread_ts=1557990483.050700=C3UDXSFA6

2019-05-16 07:13:35 UTC - Dominic Kim: @Jin Choi I am not sure this is relevant 
to your case, but when I download `csv` file via a web action, I used following 
headers:
```
'headers': { 
'Content-Type': 'text/csv',
'content-length': str(len(results)),
'Content-Encoding': 'UTF-32',
'charset': 'UTF-32LE',
'Content-Disposition': 'attachment;filename=ExportedData.csv'
},
```
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557990815051900?thread_ts=1557990815.051900=C3UDXSFA6

2019-05-16 07:15:02 UTC - Dominic Kim: You may need more headers for it.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557990902052800

2019-05-16 07:16:15 UTC - Dominic Kim: ```
Content-Encoding: gzip
```
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557990975053600

2019-05-16 07:23:54 UTC - Jin Choi: Calling a web action
``` $ curl -v -XPOST -H"Content-Type: application/json" -H"Content-Encoding: 
gzip" -d'{"name":"JIN CHOI"}' 

REQUEST HEADER
``` POST /api/v1/web/guest/demo/action.html HTTP/1.1
 Host: DOMAIN
 User-Agent: curl/7.54.0
 Accept: */*
 Content-Type: application/json
 Content-Encoding: gzip
 Content-Length: 39```

RESPONSE HEADER
``` HTTP/1.1 200 OK
 Server: nginx
 Date: Thu, 16 May 2019 07:21:49 GMT
 Content-Type: text/html; charset=UTF-8
 Content-Length: 169
 Connection: keep-alive
 X-Request-ID: 8a93c9b06347353058493ada1562e84b
 Access-Control-Allow-Origin: *
 Access-Control-Allow-Methods: OPTIONS, GET, DELETE, POST, PUT, HEAD, PATCH
 Access-Control-Allow-Headers: Authorization, Origin, X-Requested-With, 
Content-Type, Accept, User-Agent
 x-openwhisk-activation-id: 8614c025836049c294c0258360e9c23a```
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991434053700?thread_ts=1557990483.050700=C3UDXSFA6

2019-05-16 07:25:45 UTC - Jin Choi: Do you mean I need to do extra work on my 
action logic?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991545053900?thread_ts=1557990483.050700=C3UDXSFA6

2019-05-16 07:26:13 UTC - Jin Choi: For Nginx, it's just about turning on/off 
an option for gzip, isn't it?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991573054100?thread_ts=1557990483.050700=C3UDXSFA6

2019-05-16 07:27:54 UTC - Jin Choi: Whether you request a specific 
Content-Encoding is a different matter from whether you get a result in the 
requested format.
What do you see in the response header for the action call?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991674054300?thread_ts=1557990815.051900=C3UDXSFA6

2019-05-16 07:29:24 UTC - Dominic Kim: I am trying to enable gzip compression 
in a webaciton, how can I confirm the html is passed with compressions in 
chrome?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991764054500?thread_ts=1557990815.051900=C3UDXSFA6

2019-05-16 07:30:05 UTC - Jin Choi: I think you need an extension in Chrome to 
be able to tweak the options. Why don't you use `curl` on terminal?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991805054800?thread_ts=1557990815.051900=C3UDXSFA6

2019-05-16 07:30:57 UTC - Rodric Rabbah: Sure, you can try gzip on in nginx 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991857055500?thread_ts=1557990483.050700=C3UDXSFA6

2019-05-16 07:31:04 UTC - Jin Choi: Oh I think I misunderstood you.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991864055700?thread_ts=1557990815.051900=C3UDXSFA6

2019-05-16 07:31:22 UTC - Jin Choi: You can see the response header in 
`Developers Tool  Network`
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1557991882055900?thread_ts=1557990815.051900=C3UDXSFA6

2019-05-16 07:32:30 UTC - Dominic Kim: I did this but not quite sure is it 
zipped or not.
```
$ curl -SLO https://{{MY_HOST}}/api/v1/web/style95/default/gzip -H 
"Accept-Encoding: gzip" -v
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 10.106.242.22...
* Connected to {{MY_HOST}} (10.106.242.22) port 443 (#0)
* TLS 1.2 connection using 

[slack-digest] [2019-05-16] #general

[OpenWhisk Team Slack]

2019-05-16 07:46:56 UTC - Rob Allen: Right.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1557992816152600

2019-05-16 14:05:45 UTC - Vincent Hou: Does anyone know the reason for this 
issue: 
? 
Especially @dubee @Carlos Santana python2Action not found under core, but we 
have it.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1558015545154100

2019-05-16 21:01:08 UTC - Matt Rutkowski: Would appreciate all comm. members to 
take time and answer a few questions (give opinion) for our Project Maturity 
Model on the “dev” list here: 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1558040468155700

[slack-digest] [2019-05-16] #composer

[OpenWhisk Team Slack]

2019-05-16 02:21:28 UTC - Alexander Klimetschek: I am trying to use 
`composer.finally()` but it looks like it just aborts if the `body` returns an 
error, and does not invoke the `finalizer`. is that known?

or maybe I am doing something wrong… I don’t want to get in detail, but I am 
using a special conductor solution that could be the problem. just wanted to 
double check if it’s supposed to work as expected.

using composer 0.11.0


https://openwhisk-team.slack.com/archives/C7DJNS37W/p1557973288061300

2019-05-16 04:54:49 UTC - Alexander Klimetschek: note that in `body` I am doing 
a `dynamic` invoke of an action, that can fail with an error
https://openwhisk-team.slack.com/archives/C7DJNS37W/p1557982489062000

2019-05-16 05:19:15 UTC - Alexander Klimetschek: nevermind, I found the issue
https://openwhisk-team.slack.com/archives/C7DJNS37W/p1557983955062700

[slack-digest] [2019-05-16] #kubernetes

[OpenWhisk Team Slack]

2019-05-16 21:01:22 UTC - Matt Rutkowski: Would appreciate all comm. members to 
take time and answer a few questions (give opinion) for our Project Maturity 
Model on the “dev” list here: 

https://openwhisk-team.slack.com/archives/C4J3R7JFL/p1558040482005200