-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot deploy on kind because of couchdb-init failure #673
Comments
hi. What Kubernetes version (v1.18, v1.17, etc). are you running using kind? Our automated testing is currently covering v1.16, 1.17, and 1.18. We need to enable testing for 1.19 and 1.20 in travis-ci, but haven't gotten around to it yet... |
Thanks for your reply. Indeed, kind automatically picked v1.20. |
It worked for me last night using kind 0.10 on MacOS Docker Desktop (aka my laptop) and Kubernetes v1.18.5. But I realized that I deployed the latest chart from git, not the 1.0.0 chart from the helm repo. I will try that later tonight just to make sure it isn't some problem with the chart itself. |
Probably not surprising, but on my MacOS / Docker Desktop, installing the 1.0.0 helm chart on kind 0.10 works. Here's the beginning snippet of the log from the init-couchdb job.
I'm not sure exactly what |
Thanks again for checking. I followed your suggestion and tried executing the command on which Ansible fails ( At this point, I am even more confused about the problem. It is probably related to my own environment (maybe Docker version? I am using Docker 20.10.3 on Linux). I will verify if the same thing happens on a different Linux machine, as soon as I have some time to do so. |
I confirm everything works on a different Linux machine. So the issue is caused by something in my own configuration, although I haven't realized what exactly. |
I just came across the same problem. It turns the timeout is caused by Python rather than My system runs Arch Linux also, and inside the container |
It seems that the "bug" is also to use Python 2: OpenWhisk uses a Docker image of CouchDB 2.3.1, that is based on Debian Buster (slim) where the only variant of Python is Python 2... I won't try to run OpenWhisk with CouchDB 3 because I have no idea what that would imply. However, it means another valid workaround is to "fix" the environment where Ansible run (i.e., the CouchDB container when initializing the DB) by adding Do you think this could be a valid fix to this problem, that could be merged? As a way to deal with a wart from the obsolete Python 2. I find it cleaner, clearer, and easier to implement than to patch some Ansible plugin file. |
If still using Python 2, it's def better to move to v3 instead. |
Sure, but as I said, using Python 2 comes from using CouchDB 2.3.1 Docker image. I don't know if OpenWhisk can work with v3, which hopefully is based on a more up-to-date Debian image. |
I came across the same issue on Arch Linux, this fix also worked for me. |
I am trying to deploy OpenWhisk on my Arch Linux machine using kind.
I have 2 worker nodes in the cluster and I have labelled them according to the official guide. I deploy OW using the official heml chart.
This is the output of
kubectl get pods -n openwhisk
:and
kubectl logs -n openwhisk owdev-init-couchdb-sqqhp
:I verified that the issue does not appear when using Minikube (using both Docker and containerd as container runtime), so I think the issue is somehow related to kind.
My
whisk.yml
configuration is identical to that shown in the guide for deploying OW on kind (except for the apiHostName, which I set as indicated).Thanks in advance for any hint
The text was updated successfully, but these errors were encountered: