apache / couchdb-helm Goto Github PK
View Code? Open in Web Editor NEWApache CouchDB Helm Chart
Home Page: https://couchdb.apache.org/
License: Apache License 2.0
Apache CouchDB Helm Chart
Home Page: https://couchdb.apache.org/
License: Apache License 2.0
Hi,
would it be possible to support setting a IngressClass?
Thanks
Regards,
Kilian
Describe the bug
If your namespace has a deny-all network policy in place pods get crashing. If the chart has the option to enable networking it should set correct network policies:
I think its standard practice to have deny-all traffic, maybe other users faced similar problems before.
Version of Helm and Kubernetes:
Helm version: v3.2.1
k8s version: 1.18
What happened:
Chart not setting correct network policies as described in the description above.
What you expected to happen:
The chart should set correct network policies. Keeping in mind cluster has deny-all policy set already.
How to reproduce it (as minimally and precisely as possible):
Create deny-all network policy and try to install chart. Pods get crashing all the time for readiness probe.
Anything else we need to know:
I have a fix :P
It should include these policies based on some flag maybe
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: allow-egress-to-kube-dns
spec:
egress:
- ports:
- port: 53
protocol: UDP
to:
- namespaceSelector:
matchLabels:
kube-system: "true"
podSelector:
matchLabels:
app: couchdb
release: aptrack-db
policyTypes:
- Egress
---
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: allow-pod-to-pod
namespace: aptrack-db-int
spec:
egress:
- ports:
- port: 5984
protocol: TCP
- ports:
- port: 9100
protocol: TCP
- port: 4369
protocol: TCP
to:
- podSelector:
matchLabels:
app: couchdb
release: aptrack-db
podSelector:
matchLabels:
app: couchdb
release: aptrack-db
ingress:
- ports:
- port: 5984
protocol: TCP
- from:
- podSelector:
matchLabels:
app: couchdb
release: aptrack-db
ports:
- port: 9100
protocol: TCP
- port: 4369
protocol: TCP
podSelector:
matchLabels:
app: couchdb
release: aptrack-db
policyTypes:
- Ingress
- Egress
Describe the bug
The auto-generated erlang cookie (#68) changes on each helm deployment. As a result, it causes issues with rolling over the cluster.
Version of Helm and Kubernetes: 3.8.3 and 1.21
What happened: Each time we roll over the cluster (i.e. deploy config changes), it short circuits on replication failure b/c the two CouchDB nodes are running with different cookies. As a result, it never completes roll-over and stops with one restarted unhealthily:
NAME READY STATUS RESTARTS AGE
couch-1-couchdb-0 1/1 Running 0 105m
couch-1-couchdb-1 0/1 Running 0 61m
What you expected to happen: Roll over the cluster happily
How to reproduce it (as minimally and precisely as possible): Deploy helm chart twice w/ different config and replicas > 1
Anything else we need to know:
Potentially related to #77
Possible fix is to use a stateful generation pattern like #74
Alternatively, could make clear in the docs that setting the erlangFlags.setcookie
value is required in order for "rollover" to happen cleanly, change the update policy for the chart, etc.
Related: if you set this variable, then it passes as a command line argument and not as a secret env var. This should be able to be toggled independently IMO (since an HA cluster being able to restart safely / consistently depends on consistency here, and some people prefer using secrets)
Describe the bug
When setting ingress.enabled
to true
, helm install
fails with:
Error: render error in "couchdb/templates/ingress.yaml": template: couchdb/templates/ingress.yaml:23:28: executing "couchdb/templates/ingress.yaml" at <.Values.ingress.path>: can't evaluate field Values in type interface {}
Version of Helm and Kubernetes:
helm: v2.15.1
kubernetes: v1.15.0
How to reproduce it (as minimally and precisely as possible):
helm install couchdb/couchdb --set ingress.enabled=true
#8 Fixes this
Returns a 404: https://apache.github.io/couchdb-helm
We are using couchdb in the LF Acumos project, and we depend upon the couchdb helm chart (was using the one in https://github.com/helm/charts/tree/master/stable/couchdb, which has been
deprecated). I need to have a reliable helm chart repo I can refer to. As fallback I can clone this repo but I do not have the BW really to maintain my own version of this chart (though there are issues that might force that, nonetheless)... so I will appreciate a working link to a supported replacement for the "official" helm chart in a helm repo, ASAP
Is your feature request related to a problem? Please describe.
Yes. On first deployment of the couchdb helm chart, I need to create the adminSecret
myself
Describe the solution you'd like
There is a pattern I have recently been made aware of in helm charts to create an extraObjects value, evaluated as a template (similar to discussion on traefik/traefik-helm-chart#588 ), which allows deploying supporting kubernetes resources along with the traefik deployment.
In many cases, it can avoid the need for additional (fake helm chart w/ a few resources), extended (chart that extends the couchdb chart), or adhoc deployments (kubectl apply and friends).
We discussed before adding to our helm charts here: rstudio/helm#115
I'm not sure if Bitnami deserves the original credit, but they call their value extraDeploy
. We thought extraObjects
was a better name in our context ๐คท
In any case, I would be happy to write a PR with the functionality if it seems like a welcome addition. In particular, we would use it immediately for:
Our implementation:
https://github.com/rstudio/helm/blob/ac2ad2b2e3c84309a456f6229934e5170c82164e/charts/rstudio-library/templates/_tplvalues.tpl#L6-L14
Describe alternatives you've considered
Create secret manually, wrap this helm chart into another, or create a little "secret" helm chart that just deploys the secret
Additional context
Is your feature request related to a problem? Please describe.
If you haven't interacted with the service in a while, it's easy to forget how adminHash
and adminPassword
values interact.
Describe the solution you'd like
We can't put the mental model into the mind of users / administrators. However, it would be possible to add a NOTES.txt
message if both are set, so that there is clear feedback on the difference between them / etc.
Describe alternatives you've considered
There may be something smart we can do about the values or documentation so that people do not get in this place. I know I have had issues in the past with charts such as postgresql
and trying to figure out which values are being set and which are being ignored.
Another alternative would be to print out the command that can retrieve the password. This is a convention that I have noticed the postgresql chart (and others) uses.
Additional context
#74
Describe the bug
CI is failing on main
Version of Helm and Kubernetes:
What happened:
It's buried in the logs, but this seems to be the closest message I could find (this was in the events)
Error: UPGRADE FAILED: timed out waiting for the condition
...
4m26s Warning Unhealthy pod/couchdb-bn6xfmonab-couchdb-2 spec.containers{couchdb} kubelet, chart-testing-control-plane Readiness probe failed: Get "http://10.244.0.11:5984/_up": dial tcp 10.244.0.11:5984: connect: connection refused 4m26s 1 couchdb-bn6xfmonab-couchdb-2.16fa469e8b01115a
...
5m3s Warning FailedToUpdateEndpoint endpoints/couchdb-bn6xfmonab-svc-couchdb endpoint-controller Failed to update endpoint couchdb-bn6xfmonab/couchdb-bn6xfmonab-svc-couchdb: Operation cannot be fulfilled on endpoints "couchdb-bn6xfmonab-svc-couchdb": the object has been modified; please apply your changes to the latest version and try again 5m3s 1 couchdb-bn6xfmonab-svc-couchdb.16fa4695ef4ad529
I am suspicious that the issue with "upgrade" failing is related to #78
What you expected to happen: Pass CI
How to reproduce it (as minimally and precisely as possible): Look at CI on main ๐
Anything else we need to know:
Describe the bug
I followed the instructions to add a repo from here
when I run the command helm install mycouchdb couchdb/couchdb
I get the following error
Error: execution error at (couchdb/templates/configmap.yaml:12:54): A value for couchdbConfig.couchdb.uuid must be set
Version of Helm and Kubernetes:
helm I am running the development version of it by builing master
Kubernetes: I am running minikube
minikube version: v1.12.3
commit: 2243b4b97c131e3244c5f014faedca0d846599f5-dirty
What happened:
Error: execution error at (couchdb/templates/configmap.yaml:12:54): A value for couchdbConfig.couchdb.uuid must be set
What you expected to happen:
Expected couchdb to be installed
How to reproduce it (as minimally and precisely as possible):
See "Describe the bug section" above
Describe the bug
When using a Kubernetes setup with a custom DNS cluster domain suffix (like is required with a GKE VPC-scoped Cloud DNS), the post-install job will fail because of a hard-coded cluster.local
domain part.
While it is possible to override the DNS clusterDomainSuffix as a Helm value dns.clusterDomainSuffix
, this value apparently is not used by the post-install job (only in the ConfigMap used by the couchdb pods).
Version of Helm and Kubernetes:
(irrelevant)
What happened:
(see description above)
What you expected to happen:
Helm chart working with a custom cluster domain suffix.
How to reproduce it (as minimally and precisely as possible):
Install couchdb in a Kubernetes cluster with a non-default DNS suffix (i.e. not cluster.local
).
Is your feature request related to a problem? Please describe.
As discussed in #80 , keeping values.yaml
in sync with README.md
can be tricky. As a result, a tool called helm-docs
has been developed that uses go-templating to auto-generate the README.md
Describe the solution you'd like
Use GitHub Actions / CI to auto-generate helm-docs
output / keep the README.md documentation up to date with values.yaml
Describe alternatives you've considered
Manual maintenance as is currently done
Additional context
I have started on an implementation of this, which has generated some questions:
couchdb-helm
currently displays "selections" of values. i.e. "these values are for XYZ, these are for ABC". Is this desirable to maintain? helm-docs
does not currently support this idea, but I have created an issue to track doing so, because it seems nice
README.md
is quite concise (i.e. one sentence) and docs in values.yaml
are quite thorough. If auto-generating, is it OK for README.md to become more verbose in line with values.yaml
?Describe the bug
https://github.com/apache/couchdb-helm/blob/master/couchdb/templates/service.yaml
There is no option of loadbalancerIP
We should have something like
{{- if eq .Values.service.type "LoadBalancer" }}
{{- if not (empty .Values.service.loadBalancerIP) }}
loadBalancerIP: {{ .Values.service.loadBalancerIP }}
{{- end }}
{{- if .Values.service.loadBalancerSourceRanges }}
loadBalancerSourceRanges: {{- toYaml .Values.service.loadBalancerSourceRanges | nindent 4 }}
{{- end }}
{{- end }}
{{- if .Values.service.externalIPs }}
externalIPs: {{- toYaml .Values.service.externalIPs | nindent 4 }}
{{- end }}
It would be useful to automatically run the chart install test defined in e2e-kind.sh
when a PR is submitted.
Describe the bug
Couchdb pods are continuously crashing under OpenShift.
Version of Helm and Kubernetes:
Helm
$ helm version
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
OpenShift
$ oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO
Server https://127.0.0.1:8443
kubernetes v1.11.0+d4cacc0
What happened:
Deployed the couchdb helm chart, and the pods are continually crashing.
Deployment commands:
helm repo add couchdb https://apache.github.io/couchdb-helm
helm install --name acumos-couchdb --namespace acumos
--set service.type=NodePort --set allowAdminParty=true couchdb/couchdb
What you expected to happen:
Couchdb pods should become ready. This happens as expected under generic kubernetes.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
Hi guys
I think this chart is very useful in a k8s cluster but (and maybe it's just me missing out stuff) I think the community/this chart is missing some support / best practices for auto-scaling (increasing the number of couchdb nodes inside a k8s cluster)
It's quite clear that all of us want to deploy within a k8s cluster, in a cloud, because we can scale out (and in) based on various metrics.
We have been working on a azure aks setup with SSDs as data storage support for couchdb and our business services.
Now, what the stress testing revealed was the fact that the couchdb, in our case at least, is using intensively the CPU and we do want to get prepared for such bursts but in a automated way.
The obvious solution is to use Cluster Autoscaler + Horizontal Pod Autoscaler, so that we can add (and remove) a new node and a new pod (pods), on demand.
But ,the problem is (and this is here where I might be wrong) is that the couchdb cluster needs to be updated manually.
More than that, if we do have a big amount of data, how do we properly set up the new node to be "warm" when is added in the cluster (meaning replicating physically the data drive if that's even an option, so that the cluster itself won't sync internally which from our experiments seem to use quite some resources).
I did go through the couchdb docs, couch helm chart files, various documentation sources and I wasn't able to find any automated way of doing this.
We are setting up the cluster via calls to the http /_cluster_setup endpoint which is fine if we do it manually, but if the autoscaling happens automatically, the new node would be basically of no use until is added to cluster, manually.
So, if possible, pls share with us any best practices or even mechanisms that could help automate this job.
Thanks
Currently, the ingress path is hardcoded to be /
. It would be really great if the ingress path could become configurable in values.yaml
:). This is the only hardcoded value preventing my team from using this chart directly (we use path based routing). Couchdb should work out of the box with a configurable ingress path, when used in conjunction with the Rewrite Annotation.
Describe the bug
In my work on #42, I'm unable to successfully run the test suite, even on master
. I've tried kind 0.9.0, as well as 0.8.1, which @willholley has reported successfully works for him.
Version of Helm and Kubernetes:
docker-ce
version 18.06.3~ceWhat happened:
$ make test
./test/e2e-kind.sh
Running ct container...
9e16a8d8640fdfa36003c17e4ca5d16a9fb13818eda235ad6fc29bb9a2ddc4ae
Deleting cluster "chart-testing" ...
Creating cluster "chart-testing" ...
โ Ensuring node image (kindest/node:v1.18.2) ๐ผ
โ Preparing nodes ๐ฆ ๐ฆ
โ Writing configuration ๐
โ Starting control-plane ๐น๏ธ
โ Installing CNI ๐
โ Installing StorageClass ๐พ
โ Joining worker nodes ๐
โ Waiting โค 1m0s for control-plane = Ready โณ
โข Ready after 0s ๐
Set kubectl context to "kind-chart-testing"
You can now use your cluster with:
kubectl cluster-info --context kind-chart-testing
Thanks for using kind! ๐
Copying kubeconfig to container...
error: Missing or incomplete configuration info. Please point to an existing, complete config file:
1. Via the command-line flag --kubeconfig
2. Via the KUBECONFIG environment variable
3. In your home directory as ~/.kube/config
To view or setup config directly use the 'config' command.
Removing ct container...
Deleting cluster "chart-testing" ...
Done!
make: *** [Makefile:31: test] Error 1
What you expected to happen:
Tests pass.
How to reproduce it (as minimally and precisely as possible):
GO111MODULE="on" go get sigs.k8s.io/[email protected] && kind create cluster
)make test
Anything else we need to know:
I expect this is related to my local kubernetes config not matching what the tests expect. It probably just needs a small update to the README mentioning whatever the missing requirement is.
I have installed couchdb using helm chart with enableSearch=True.
But when i try to use this feature i have the error below:
{"error":"ou_est_clouseau","reason":"Could not connect to the Clouseau Java service at [email protected]"}
On couchdb container:
[error] 2020-06-25T00:26:58.145625Z couchdb@couchdb-couchdb-0.couchdb-couchdb.xxxxx.svc.cluster.local <0.7163.148> -------- ** '[email protected]': Connection attempt to node '[email protected]' aborted since it cannot handle ["UTF8_ATOMS"].**
On clouseau container:
2020-06-25 00:25:06,578 scalang.node.ServerHandshakeHandler [ERROR] Channel closed during handshake
2020-06-25 00:25:06,579 scalang.node.ErlangHandler [DEBUG] handler message HandshakeFailed('[email protected])
2020-06-25 00:25:06,580 scalang.node.ErlangHandler [INFO] channel disconnected org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext@41840958 [id: 0x547d090e, /127.0.0.1:36385 :> /127.0.0.1:46791] DISCONNECTED. peer: null
Anyone can help me?
Describe the bug
unable to setup couch db on ipv6 only environemnt
Version of Helm and Kubernetes:
CouchDB - 3.3.4
Kubernetes: 1.22
What happened:
After installing the chart the pods are in CrashLoopBackOff and getting the below logs from couchdb container
eic@devgpu01:~> kubectl get pods -n tycoai-db
NAME READY STATUS RESTARTS AGE
couchdb-couchdb-0 0/2 CrashLoopBackOff 15 (4m58s ago) 18m
eic@devgpu01:~> kubectl logs -n tycoai-db couchdb-couchdb-0 -c couchdb
2022-10-20 03:59:11 Can't set long node name!
Please check your configuration
2022-10-20 03:59:11 crash_report
{net_kernel,init,['Argument__1']}
<0.27.0>
[]
{exit,{error,badarg},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,349}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
[net_sup,kernel_sup,<0.14.0>]
0
[]
[<0.24.0>]
[{longnames,true}]
true
running
1598
27
927
initial_call: pid: registered_name: error_info: ancestors: message_queue_len: messages: links: dictionary: trap_exit: status: heap_size: stack_size: reductions: 2022-10-20 03:59:11 supervisor_report
{local,net_sup}
start_error
{'EXIT',nodistribution}
[{pid,undefined},{id,net_kernel},{mfargs,{net_kernel,start_link,[[couchdb,longnames],true]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]
{local,kernel_sup}
start_error
{shutdown,{failed_to_start_child,net_kernel,{'EXIT',nodistribution}}}
[{pid,undefined},{id,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]
supervisor: errorContext: reason: offender: 2022-10-20 03:59:11 supervisor_report
{application_master,init,['Argument__1','Argument__2','Argument__3','Argument__4']}
<0.13.0>
supervisor: errorContext: reason: offender: 2022-10-20 03:59:11 crash_report
[]
{exit,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,net_kernel,{'EXIT',nodistribution}}}}},{kernel,start,[normal,[]]}},[{application_master,init,4,[{file,"application_master.erl"},{line,134}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
[<0.12.0>]
1
[{'EXIT',<0.14.0>,normal}]
[<0.12.0>,<0.11.0>]
[]
true
running
376
27
214
initial_call: pid: registered_name: error_info: ancestors: message_queue_len: messages: links: dictionary: trap_exit: status: heap_size: stack_size: reductions: 2022-10-20 03:59:11 std_info
kernel
{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,net_kernel,{'EXIT',nodistribution}}}}},{kernel,start,[normal,[]]}}
permanent
{"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,net_kernel,{'EXIT',nodistribution}}}}},{kernel,start,[normal,[]]}}}"}
application: exited: type: Kernel pid terminated (application_controller) ({application_start_failure,kernel,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,net_kernel,{'EXIT',nodistribution}}}}},{ker
Crash dump is being written to: erl_crash.dump...done
How to reproduce it (as minimally and precisely as possible):
Setup a ipv6 only kuberentes cluster
install any storage backend, we are using openEBS
and install couchdb on that
Describe the bug
The CouchDB helm chart has an issue with annotations key.
You can find the error in this line: https://github.com/apache/couchdb-helm/blob/main/couchdb/templates/statefulset.yaml#L23
Version of Helm and Kubernetes:
What happened:
An error occurs if we use the top annotations
key in a custom values file:
annotations:
sidecar.istio.io/inject: "false"
The error:
Error: UPGRADE FAILED: template: smb-cluster/charts/modb/templates/statefulset.yaml:23:28: executing "smb-cluster/charts/modb/templates/statefulset.yaml" at <include (print $.Template.BasePath "/configmap.yaml") .>: error calling include: template: smb-cluster/charts/db/templates/_helpers.tpl:14:14: executing "couchdb.fullname" at <.Values.fullnameOverride>: nil pointer evaluating interface {}.fullnameOverride
What you expected to happen:
We expect it works...
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
You should replace "." with "$" when you pass the parameter to include func, because you use with
block before and "." inside this block is not the root context.
So instead of this:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
It should be:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") $ | sha256sum }}
Describe the bug
The cluster setup wizard does not work in microk8s, while it does work in k3s, kind, and minikube.
The setup command is
curl -s http://127.0.0.1:5984/_cluster_setup -X POST -H "Content-Type: application/json" -d '{"action": "finish_cluster"}' -u admin
executed on one of the nodes within k8s, as per the chart's Note.
Version of Helm and Kubernetes:
Helm v3.6.3
Kubernetes v1.21.11 (via microk8s)
What happened:
{"error":"setup_error","reason":"Cluster setup timed out waiting for nodes to connect"}
What you expected to happen:
Successful completion of setup wizard, creation of _users
and _replication
table, etc
How to reproduce it (as minimally and precisely as possible):
Install microk8s
sudo snap install microk8s --classic --channel=1.21
(you may need more to get kubectl working)
Activate addons for microk8s; dns
and storage
are required for this config, traefik
and rbac
are also installed for replication
microk8s enable dns
microk8s enable storage
Install CouchDB helm chart
kubectl create secret generic cluster-couchdb --from-literal=adminUsername=admin --from-literal=adminPassword=dbpass --from-literal=cookieAuthSecret=dbcookiepass --from-literal=erlangCookie=monster
helm install my-release couchdb/couchdb --set couchdbConfig.couchdb.uuid=$(curl https://www.uuidgenerator.net/api/version4 2>/dev/null | tr -d -) --version 3.6.1 -f ./values.yaml
with values.yaml like:
createAdminSecret: false
persistentVolume:
enabled: true
accessModes:
- ReadWriteOnce
size: 10Gi
# storageClass: "-"
I also did this with version=3.3.3 with same issue.
Anything else we need to know:
I tried on two machines, both of which were running Ubuntu 20.04. Between the two machines, I verified that this worked with all of minikube, kind and k3s.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
This is related to #7 , although that issue seems a bit dated. Basically, when createAdminSecret
is used (by default), a new secret seems that it will be generated on each release (I have yet to verify myself).
Describe the solution you'd like
In line with #73 , it is possible to generate values in such a way that they can be used consistently and preserved within Kubernetes (along with an optional user notification).
Describe alternatives you've considered
Putting the work onto the user to maintain / change these values (as is currently done)
Additional context
Depending on the outcome of #73, this would be fairly straightforward to implement within the helm chart. Wording and whether/how to notify in NOTES.txt
(i.e. once for each value? Something less verbose?) will be important to consider.
Describe the bug
On existing couchdb clusters a upgrade from version 3.6.0 to 3.6.1 with default erlang cookie will fail.
A clear and concise description of what the bug is.
Commit 625d143 removes the default value "monster" in couchdb/values.yaml
for erlang cookie.
If no custom cookie value was defined in values.yaml, nodes cannot connect to existing cluster nodes.
Version of Helm and Kubernetes:
helm: v3.7.2
k8s: 1.23.8, 1.23.16 & 1.24.10
What happened:
Upgraded Pod will not start and cannot connect to cluster nodes.
What you expected to happen:
Upgrade should work.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
Workaround:
Add erlang flags section into values.yaml
erlangFlags:
name: couchdb
setcookie: monster
Installation of v3.6.1
of the couchdb helm chart in a k8s cluster managed by Rancher fails. Pods enter a CrashLoopBackOff state with the log message
Monster detected ohno!, aborting startup.
Please change the Erlang cookie in vm.args to the same
securely generated random value on all nodes of this cluster.
I created a secret my-release-couchdb
in the same namespace:
admin
myPassword
mySecret
monster
I tried with and without the erlangCookie
key, also I tried setting the erlangFlags.setcookie=monster
in the values.yaml
, both to no avail. The values.yaml
is shown below. They are mostly the defaults.
adminUsername: admin
affinity: {}
allowAdminParty: false
annotations: {}
clusterSize: 3
couchdbConfig:
chttpd:
bind_address: any
require_valid_user: false
couchdb:
uuid: bbeb004f-11ad-44bd-8300-900fcb9600a2
createAdminSecret: false
dns:
clusterDomainSuffix: cluster.local
enableSearch: false
erlangFlags:
name: couchdb
image:
pullPolicy: IfNotPresent
repository: couchdb
tag: 3.2.2
ingress:
annotations: []
enabled: false
hosts:
- chart-example.local
path: /
tls: null
initImage:
pullPolicy: Always
repository: busybox
tag: latest
livenessProbe:
enabled: true
failureThreshold: 3
initialDelaySeconds: 0
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
networkPolicy:
enabled: true
persistentVolume:
accessModes:
- ReadWriteOnce
enabled: true
size: 10Gi
placementConfig:
enabled: false
image:
repository: caligrafix/couchdb-autoscaler-placement-manager
tag: 0.1.0
podManagementPolicy: Parallel
prometheusPort:
bind_address: 0.0.0.0
enabled: false
port: 17986
readinessProbe:
enabled: true
failureThreshold: 3
initialDelaySeconds: 0
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources: {}
searchImage:
pullPolicy: IfNotPresent
repository: kocolosk/couchdb-search
tag: 0.2.0
service:
enabled: true
externalPort: 5984
type: ClusterIP
serviceAccount:
create: true
enabled: true
sidecars: {}
tolerations: []
topologySpreadConstraints: {}
Describe the bug
When configuring couchdb inside of the helm chart, one class of configuration involves hardening / tweaking the authentication configuration. It is possible to change this in such a way that the chart readiness probes are not able to reconcile, the cluster is not able to talk to each other, etc.
Version of Helm and Kubernetes:
K8s 1.21, Helm 3.8.2
What happened:
Set require_valid_user: true
and couchdbConfig.chttpd.authentication_handlers
to a non-default value. Connections within the cluster replication started failing, and health checks / readiness probes were returning unhealthy
What you expected to happen:
Change configuration and things continue working.
How to reproduce it (as minimally and precisely as possible):
Set require_valid_user: true
and couchdbConfig.chttpd.authentication_handlers
to not include: "{chttpd_auth, default_authentication_handler}"
(the readinessProbe uses basic auth)
Anything else we need to know:
Some possible solutions:
readinessProbe
so that someone can override the defaults if they would likerequire_valid_user: true
essentially makes Fauxton not functional unless you already have auth taken care of on your network traffic (basic, JWT, etc.)? If so, some docs on that inside of the couchdb docs could be helpful too.Describe the bug
After restarting a pod, the node fails to join the cluster properly, and we're getting an error on Fauxton, that displays 'this database failed to load' on some databases. when refreshing the browser, a different db comes online and a different db displays 'this database failed to load'. only after running a curl request with 'finish_cluster' the error stops.
Version of Helm and Kubernetes: Helm: 3.5.4, Kubernetes: 1.19
What happened: After restarting a pod, the node fails to join the cluster properly, and only after running:
curl -X POST http://$adminUser:$adminPassword@<couchdb_pod>:5984/_cluster_setup -H "Accept: application/json" -H "Content-Type: application/json" -d '{"action": "finish_cluster"}'
The pod will join back to the cluster.
What you expected to happen: After restart of the pod, the node automatically joins the cluster.
How to reproduce it (as minimally and precisely as possible): restart 1 pod in the cluster.
Anything else we need to know:
Adding image from Fauxton regarding this database failed to load:
Also added the values.yaml:
clusterSize: 3
allowAdminParty: false
createAdminSecret: false
adminUsername: admin
networkPolicy:
enabled: true
serviceAccount:
enabled: true
create: true
persistentVolume:
enabled: true
accessModes:
- ReadWriteOnce
size: 10Gi
storageClass: "ssd-couchdb"
image:
repository:
tag: latest
pullPolicy: Always
searchImage:
repository: kocolosk/couchdb-search
tag: 0.2.0
pullPolicy: IfNotPresent
enableSearch: false
initImage:
repository: busybox
tag: latest
pullPolicy: Always
podManagementPolicy: Parallel
affinity: {}
annotations: {}
tolerations: []
service:
enabled: true
type: LoadBalancer
externalPort: 5984
sidecarsPort: 8080
LoadBalancerIP:
ingress:
enabled: false
hosts:
- chart-example.local
path: /
annotations: []
tls:
resources:
{}
erlangFlags:
name: couchdb
setcookie: monster
couchdbConfig:
chttpd:
bind_address: any
require_valid_user: false
dns:
clusterDomainSuffix: cluster.local
livenessProbe:
enabled: true
failureThreshold: 3
initialDelaySeconds: 0
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
enabled: true
failureThreshold: 3
initialDelaySeconds: 0
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
sidecars:
image: "<sidecar_image>"
imagePullPolicy: Always
Hello,
First of all, thank you for the work put here!
Upon inspecting parameters and values, I wasn't quite sure how to setup local.ini
to include
[native_query_servers]
enable_erlang_query_server = true
could it be done via couchdbConfig
, or is it not possible as of now?
If possible, could I get an example?
Describe the bug
I get a warning coalesce.go:160: warning: skipped value for affinity: Not a table.
when trying to install with affinity set in my values file
Version of Helm and Kubernetes:
Helm: 3.2.1
Kubernetes: 1.17.5
What happened:
When installing, I get a warning: coalesce.go:160: warning: skipped value for affinity: Not a table.
Warnings cause my deployment pipeline to abort, so I need to get this fixed
What you expected to happen:
The helm install should succeed without warnings
How to reproduce it (as minimally and precisely as possible):
Create repro.yaml:
couchdbConfig:
couchdb:
uuid: 123
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- couchdb
topologyKey: "kubernetes.io/hostname"
Then run helm install my-name couchdb/couchdb -f repro.yaml
Anything else we need to know:
It seems to be tied to having affinity:
defined in values.yaml without any children. If I comment out this line, the release succeeds without errors and creates the affinity
couchdb-helm/couchdb/values.yaml
Line 87 in deb055f
I know this isn't the only place that a key is defined without children though, so I'm trying to figure out if there's a better way.
Is your feature request related to a problem? Please describe.
After deploying the helm chart, there is a very helpful / explanatory message in NOTES.txt
about cluster state:
Once all of the Pods are fully Ready, execute the following command to create
some required system databases
Describe the solution you'd like
It would be nice if this manual command did not need to be run. What is it for? Is there a way to deploy a one-shot job or something alongside that will do this bootstrapping for us? What are the downsides if you run this command multiple times?
At a minimum, the quoting on the command was a little off which made it tricky to use
Describe alternatives you've considered
Additional context
It also surprises me that this is printed every time. I suspect there are values in helm that we could use to determine whether this is necessary to print. For instance, I'm pretty sure you can tell when you have an install
vs. an upgrade
.
couchdb-helm/couchdb/templates/NOTES.txt
Lines 5 to 8 in 78eff8c
Upon executing helm install couchdb -n couchdb couchdb/couchdb -f values.yaml, the main container enters a continuous restart loop, lacking explanatory logs. This issue surfaces when persistence is enabled; without it, the container starts successfully. The PVC and PV are properly created, mounted and writable ( i tested from another container ).
Experimenting with a custom Deployment resulted in same behaviour. Consequently, the issue could originate from my storage configuration or permissions and how the docker container or the software expects them. It's noteworthy that other applications (Prometheus, RabbitMQ) operate without issues on the same storage. cluster, helm.
Any information or further steps will be appreciated. Thank you!
Version of Helm and Kubernetes:
Provider: Amazon EKS, Kubernetes Version: v1.24.13 -0a21954
version.BuildInfo{Version:"v3.9.4", GitCommit:"dbc6d8e20fe1d58d50e6ed30f09a04a77e4c68db", GitTreeState:"clean", GoVersion:"go1.17.13"}
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: efs-storage-class-wa
allowVolumeExpansion: true
parameters:
basePath: /dynamic_provisioning
directoryPerms: '700'
fileSystemId: <fs>
gidRangeEnd: '2000'
gidRangeStart: '1000'
provisioningMode: efs-ap
provisioner: efs.csi.aws.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
The StatefulSet is unable to start with Amzon EFS Persistence Storage
Create EFS Storage on EKS and deploy following the guide in the README.
# -- the initial number of nodes in the CouchDB cluster.
clusterSize: 1
persistentVolume:
enabled: true
storageClass: "efs-storage-class-wa"
accessModes:
- ReadWriteOnce
size: 10Gi
networkPolicy:
enabled: false
image:
tag: 3.3.2
dns:
clusterDomainSuffix: cluster.local
service:
enabled: true
prometheusPort:
enabled: true
bind_address: "0.0.0.0"
port: 8080
couchdbConfig:
chttpd:
bind_address: any
require_valid_user: false
couchdb:
uuid: 4714aa87edb4be946671309fbec8941a
Name: couchdb-qa-couchdb-0
Namespace: couchdb-qa
Priority: 0
Node: ip-10-152-181-13.eu-west-1.compute.internal/10.152.181.13
Start Time: Wed, 07 Jun 2023 12:34:11 +0300
Labels: app=couchdb
controller-revision-hash=couchdb-qa-couchdb-b6c8db589
release=couchdb-qa
statefulset.kubernetes.io/pod-name=couchdb-qa-couchdb-0
Status: Running
Controlled By: StatefulSet/couchdb-qa-couchdb
Init Containers:
init-copy:
Container ID: containerd://de3c35142624b77f0c8abcca439f5b436ac0a23666e88cf0a5274f00e6558ca8
Image: busybox:latest
Image ID: docker.io/library/busybox@sha256:560af6915bfc8d7630e50e212e08242d37b63bd5c1ccf9bd4acccf116e262d5b
Port: <none>
Host Port: <none>
Command:
sh
-c
cp /tmp/chart.ini /default.d; cp /tmp/seedlist.ini /default.d; cp /tmp/prometheus.ini /default.d; ls -lrt /default.d;
State: Terminated
Reason: Completed
Exit Code: 0
Started: Wed, 07 Jun 2023 12:34:13 +0300
Finished: Wed, 07 Jun 2023 12:34:13 +0300
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/default.d from config-storage (rw)
/tmp/ from config (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-w5kzb (ro)
Containers:
couchdb:
Container ID: containerd://ff97bde75fd9ce3ea58d962bb8aa8e35902af2584bea4ac16ba0317d60b35a1f
Image: couchdb:3.3.2
Image ID: docker.io/library/couchdb@sha256:efd8eefd6e849ac88a5418bd4e633002e9f665fd6b16c3eb431656984203cfec
Ports: 5984/TCP, 4369/TCP, 9100/TCP, 8080/TCP
Host Ports: 0/TCP, 0/TCP, 0/TCP, 0/TCP
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: Wed, 07 Jun 2023 12:34:14 +0300
Finished: Wed, 07 Jun 2023 12:34:14 +0300
Ready: False
Restart Count: 1
Liveness: http-get http://:5984/_up delay=0s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get http://:5984/_up delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
COUCHDB_USER: <set to the key 'adminUsername' in secret 'couchdb-qa-couchdb'> Optional: false
COUCHDB_PASSWORD: <set to the key 'adminPassword' in secret 'couchdb-qa-couchdb'> Optional: false
COUCHDB_SECRET: <set to the key 'cookieAuthSecret' in secret 'couchdb-qa-couchdb'> Optional: false
COUCHDB_ERLANG_COOKIE: <set to the key 'erlangCookie' in secret 'couchdb-qa-couchdb'> Optional: false
ERL_FLAGS: -name couchdb -setcookie XXXXXXXXXXX
Mounts:
/opt/couchdb/data from database-storage (rw)
/opt/couchdb/etc/default.d from config-storage (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-w5kzb (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
database-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: database-storage-couchdb-qa-couchdb-0
ReadOnly: false
config-storage:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: couchdb-qa-couchdb
Optional: false
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4s default-scheduler Successfully assigned couchdb-qa/couchdb-qa-couchdb-0 to node1
Normal Pulling 3s kubelet Pulling image "busybox:latest"
Normal Pulled 2s kubelet Successfully pulled image "busybox:latest" in 593.012622ms
Normal Created 2s kubelet Created container init-copy
Normal Started 2s kubelet Started container init-copy
Normal Created 1s (x2 over 2s) kubelet Created container couchdb
Normal Started 1s (x2 over 2s) kubelet Started container couchdb
Warning BackOff <invalid> (x4 over 0s) kubelet Back-off restarting failed container
Defaulted container "couchdb" out of: couchdb, init-copy (init)
total 12
-rw-r--r-- 1 root root 98 Jun 7 09:34 seedlist.ini
-rw-r--r-- 1 root root 71 Jun 7 09:34 prometheus.ini
-rw-r--r-- 1 root root 106 Jun 7 09:34 chart.ini
Describe the bug
if settings annotations while installing couchdb using helm, it will fail for versions above 3.3.0.
Version of Helm and Kubernetes:
helm version(client/server): "v2.12.3"
k8s version(client/server): "v1.11.0+d4cacc0"
What happened:
it will throw errors as below:
Error: render error in "couchdb/templates/statefulset.yaml": template: couchdb/templates/statefulset.yaml:23:28: executing "couchdb/templates/statefulset.yaml" at <include (print $.Tem...>: error calling include: template: couchdb/templates/_helpers.tpl:14:14: executing "couchdb.fullname" at <.Values.fullnameOver...>: can't evaluate field fullnameOverride in type interface {}
What you expected to happen:
It should install couchdb successfully.
How to reproduce it (as minimally and precisely as possible):
3.3.1-3.3.2 would fail:
helm install --debug --dry-run --set annotations.hello=world,couchdbConfig.couchdb.uuid=xxxxyyy couchdb/couchdb --version 3.3.3
helm install --debug --dry-run --set annotations.hello=world,couchdbConfig.couchdb.uuid=xxxxyyy couchdb/couchdb --version 3.3.2
helm install --debug --dry-run --set annotations.hello=world,couchdbConfig.couchdb.uuid=xxxxyyy couchdb/couchdb --version 3.3.1
3.3.0 succeed:
helm install --debug --dry-run --set annotations.hello=world,couchdbConfig.couchdb.uuid=xxxxyyy couchdb/couchdb --version 3.3.0
Anything else we need to know:
nope.
Would it be reasonable to create the _users
database upon cluster initialization? If it doesn't make sense in all cases, would it be reasonable to do it optionally if a config value (createUsersDatabase = true
?) is set?
If this is something we want, I'm happy to work on a PR.
I'm not sure of the best approach. One possibility would be to create a Job
resource that effectively calls curl -X PUT http://.../_users
. There might be some cleaner way I haven't thought of. I'm eager to hear other suggestions, if this is deemed worth pursuing.
Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
I would like to have a Helm chart for CouchDB version 3.0.0
and/or 3.1.0
.
Describe alternatives you've considered
A naive alternative might be setting image.tag
in values to 3.0.0
or 3.1.0
. But I do not expect that to work.
Additional context
I am new to CouchDB, so I am not familiar with differences between 2.x
and 3.x
versions. We are considering CouchDB for deployments to on-premise Kubernetes clusters where we need an alternative for managed document databases that we use in cloud.
Describe the bug
From Helm v3 the chart installation is:
helm install [NAME] [CHART] [flags]
Therefore there is need to update the installation commands in the guide to this new format.
Version of Helm and Kubernetes:
Helm: v3.7.1
K8S: Docker Desktop K8S, v1.25.0
What happened:
Error: unknown flag: --name
What you expected to happen:
Chart to install successfully
How to reproduce it (as minimally and precisely as possible):
Run the command:
helm install \
--name my-release \
--set couchdbConfig.couchdb.uuid=uuid \
couchdb/couchdb
Anything else we need to know:
LMK If I can go ahead and create a PR for this
I wonder what stance is on idempotency of the CouchDB Helm chart install action? It seems to be a debated issue in the Helm world, but one which the CouchDB Helm Chart needs to relate to.
From what I can tell, most people treat Helm actions as something which doesn't belong in a CI/CD, for the reason that they cannot interpret if the given chart provides idempotency. Helm as such makes no promises and to my knowledge there's no best practice for Helm chart developers.
Below is presumably (?) the general way to make a helm 'install' action idempotent:
helm upgrade --install couchdb couchdb/couchdb \
--version "<fixed-value>"
rather than
helm install couchdb couchdb/couchdb
With the CouchDB helm chart and with the desire to have the Secret automatically created on first-time install, this will not work. What happens is that the Secret will be updated with new values for every invocation. This will of course create havoc.
I don't know what the best solution is. CI/CD developers would want to put the helm action into their pipeline and as such they are looking for (expecting?) idempotency. At the very least, the CouchDB helm chart can document where it stands on this.
In terms of making sure the chart action is idempotent, I believe the only potential culprit is the Secret. The other Kubernetes objects are okay to be re-applied (by design). Some ideas on the Secret: Look into the use of immutable Secrets introduced in Kubernetes 1.21 or maybe have a chart option createSecretIfNotExists
. Or something.
A workaround at the moment would be to do:
#!/bin/bash
#
# check if already installed
if ! helm status -n $namespace couchdb &> /dev/null; then
helm install couchdb couchdb/couchdb \
--namespace $namespace \
...
fi
Is your feature request related to a problem? Please describe.
I'm unable to select which nodes CouchDB runs on.
Describe the solution you'd like
I'd like to be able to set the nodeSelector
value, as per https://github.com/bitnami/charts/tree/master/bitnami/redis#redis-replicas-configuration-parameters
Describe alternatives you've considered
I don't know of any other way to do this.
Additional context
n/a
A default install of the helm chart, like so:
helm install couchdb couchdb/couchdb \
--namespace $namespace \
--set couchdbConfig.couchdb.uuid=1edba19879809c3ae67e2abec4054579 \
--set persistentVolume.enabled=true
will simply not work. It may seem to work, but in reality it doesn't. Here's why: In Kubernetes everything must expect to be bounced occasionally. Perhaps your PaaS provider for the Kubernetes cluster will restart/re-cycle underlying Kubernetes Nodes on a weekly basis or whatever. This causes Pods to restart. With the above config, the adminHash will be generated on Pod startup. It will inevitably be different on different Pods. For our deployment this has meant that - after some time - you can no longer login to Fauxton. (and when that happens it produces very strange behavior/error message which I doubt anyone except 1-2 couchdb experts would ever figure out to attribute to inconsistent adminHash'es on different nodes ... but that is not the focus of this ticket).
My argument here is that the above default install is indeed a time bomb. Sooner or later it will stop working.
The solution - for us - has been to create the adminHash
ourselves and put it into the Secret which we then need produce ourselves too. This is hinted in the helm chart documentation, but as if it is optional, however it is not, you cannot really make CouchDB work (at least if using Fauxton) without force-setting the adminHash
.
Creating your own Secret is indeed a very involved process as you then need to figure out a way to auto-create all the other values in the Secret too. (I'm assuming here that everyone is using IaC these days: the goal is to use the helm chart from a deployment pipeline, not as a tool randomly fired from the command line).
In any case, creation of the Secret would look something like this:
kubectl --namespace "$k8s_namespace" \
create secret generic "$secretname" \
--from-literal=adminUsername=admin \
--from-literal=adminPassword="$adminpwd" \
--from-literal=cookieAuthSecret="$cookieauthsecret" \
--from-literal=adminHash="$adminhash" \
--from-literal=erlangCookie="$erlangcookie"
cookieAuthSecret
, erlangCookie
and adminPassword
are password-like strings. You need to find a way to auto-generate those in your pipeline.
adminHash
is worse. CouchDB uses PBKDF2 for the adminHash but stores it in a custom format. You can find a recipe here for how to create the adminHash
. The input to the hash is the value you've created for adminPassword
.
Now for the final step, you need to let the helm chart know that you've already created Secret and you want the chart to use that one. This is done like so:
helm install couchdb couchdb/couchdb \
--namespace $namespace \
--set couchdbConfig.couchdb.uuid=1edba19879809c3ae67e2abec4054579 \
--set createAdminSecret=false \
--set adminHash=loremipsum \
--set persistentVolume.enabled=true
The strange - and as far as I can tell - undocumented trick is that you need to set adminHash
as a chart value too (in addition to the fact that you just defined it in the Secret). As a chart value it doesn't matter what value it has, as long as it is set. I set it to lorem ipsum
in the example, just to make a point of this fact.
I think this could be either automated in the helm chart or (second best) be documented. In particular, I argue, that having a default recommendation for how the helm chart should be used, which in reality will not work after some time, is not good.
I hope this can be used as input for an improvement process on the helm chart.
Version of CouchDB Helm chart:
Latest at time of this ticket. (v4.5.0)
Is your feature request related to a problem? Please describe.
CouchDB provided an error on Read-Only storage but did not trigger the readiness check on the _up endpoint (default provided readiness check).
Describe the solution you'd like
I propose the current readiness check be moved to liveliness and readiness be similar to sh -c 'touch /opt/couchdb/data/.ready'. If it exits != 0 for storage issues the pod will reset which would trigger a storage mount refresh.
Describe alternatives you've considered
I've made this change in local system. It works.
Describe the bug
This repos main
branch hasn't been updated for 8 month as I'm writing this issue.
Basic features like the cluster setup & couchdb 3 are still not available/merged or [in case of CDB3] even been worked on publicly.
What you expected to happen:
I would love to see this repo getting active maintenance as we currently started using CouchDB in production. But if Apache doesn't care about it, the community or I might have to fork the project and maintain it as a community project.
Describe the bug
We have used the helm charts to install a 3 node couchdb cluster. We have noticed that one of the nodes in the cluster (coordinator node) is restarting on a regular basis, usually once a day.
The couchdb pod error is
Container couchdb failed liveness probe, will be restarted
The couchdb logs indicate the following errors:
`[notice] 2022-06-23T06:23:43.733589Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30690.22> b938e4d3fa 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 29613
[notice] 2022-06-23T06:23:45.153723Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30707.22> 7bc4d55e3e 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 14872
[notice] 2022-06-23T06:23:45.154154Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30697.22> d48973481d 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 13
[error] 2022-06-23T06:23:45.273373Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30706.22> 45a001ddb1 req_err(2751202856) timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L238">>,<<"chttpd_misc:handle_up_req/1 L274">>,<<"chttpd:handle_req_after_auth/2 L327">>,<<"chttpd:process_request/1 L310">>,<<"chttpd:handle_request_int/1 L249">>,<<"mochiweb_http:headers/6 L150">>,<<"proc_lib:init_p_do_apply/3 L226">>]
[error] 2022-06-23T06:23:45.274458Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30691.22> c975e456eb req_err(2751202856) timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L238">>,<<"chttpd_misc:handle_up_req/1 L274">>,<<"chttpd:handle_req_after_auth/2 L327">>,<<"chttpd:process_request/1 L310">>,<<"chttpd:handle_request_int/1 L249">>,<<"mochiweb_http:headers/6 L150">>,<<"proc_lib:init_p_do_apply/3 L226">>]
[notice] 2022-06-23T06:23:45.274005Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30706.22> 45a001ddb1 192.168.230.108:5984 10.1.2.179 undefined GET /_up 500 ok 15095
[notice] 2022-06-23T06:23:45.274958Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30691.22> c975e456eb 192.168.230.108:5984 10.1.2.179 undefined GET /_up 500 ok 34630
[error] 2022-06-23T06:23:45.915833Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.23685.4> -------- gen_server couch_prometheus_server terminated with reason: {timeout,{gen_server,call,[couch_stats_aggregator,fetch]}} at gen_server:call/2(line:238) <= couch_stats_aggregator:fetch/0(line:44) <= couch_prometheus_server:get_couchdb_stats/0(line:94) <= couch_prometheus_server:refresh_metrics/0(line:87) <= couch_prometheus_server:handle_info/2(line:74) <= gen_server:try_dispatch/4(line:689) <= gen_server:handle_msg/6(line:765) <= proc_lib:init_p_do_apply/3(line:226)
last msg: redacted
state: {st,<<"# TYPE couchdb_couch_log_requests_total counter\ncouchdb_couch_log_requests_total{level="alert"} 0\ncouchdb_couch_log_requests_total{level="critical"} 0\ncouchdb_couch_log_requests_total{level="debug"} 0\ncouchdb_couch_log_requests_total{level="emergency"} 0\ncouchdb_couch_log_requests_total{level="error"} 0\ncouchdb_couch_log_requests_total{level="info"} 7\ncouchdb_couch_log_requests_total{level="notice"} 18573\ncouchdb_couch_log_requests_total{level="warning"} 0\n# TYPE couchdb_couch_replicator_changes_manager_deaths_total counter\ncouchdb_couch_replicator_changes_manager_deaths_total 0\n# TYPE couchdb_couch_replicator_changes_queue_deaths_total counter\ncouchdb_couch_replicator_changes_queue_deaths_total 0\n# TYPE couchdb_couch_replicator_changes_read_failures_total counter\ncouchdb_couch_replicator_changes_read_failures_total 0\n# TYPE couchdb_couch_replicator_changes_reader_deaths_total counter\ncouchdb_couch_replicator_changes_reader_deaths_total 0\n# TYPE couchdb_couch_replicator_checkpoints_failure_total counter\ncouchdb_couch_replicator_checkpoints_failure_total 0\n# TYPE couchdb_couch_replicator_checkpoints_total counter\ncouchdb_couch_replicator_checkpoints_total 0\n# TYPE couchdb_couch_replicator_cluster_is_stable gauge\ncouchdb_couch_replicator_cluster_is_stable 1\n# TYPE couchdb_couch_replicator_connection_acquires_total counter\ncouchdb_couch_replicator_connection_acquires_total 0\n# TYPE couchdb_couch_replicator_connection_closes_total counter\ncouchdb_couch_replicator_connection_closes_total 0\n# TYPE couchdb_couch_replicator_connection_creates_total counter\ncouchdb_couch_replicator_connection_creates_total 0\n# TYPE couchdb_couch_replicator_connection_owner_crashes_total counter\ncouchdb_couch_replicator_connection_owner_crashes_total 0\n# TYPE couchdb_couch_replicator_connection_releases_total counter\ncouchdb_couch_replicator_connection_releases_total 0\n# TYPE couchdb_couch_replicator_connection_worker_crashes_total counter\ncouchdb_couch_replicator_connection_worker_crashes_total 0\n# TYPE couchdb_couch_replicator_db_scans_total counter\ncouchdb_couch_replicator_db_scans_total 1\n# TYPE couchdb_couch_replicator_docs_completed_state_updates_total counter\ncouchdb_couch_replicator_docs_completed_state_updates_total 0\n# TYPE couchdb_couch_replicator_docs_db_changes_total counter\ncouchdb_couch_replicator_docs_db_changes_total 0\n# TYPE couchdb_couch_replicator_docs_dbs_created_total counter\ncouchdb_couch_replicator_docs_dbs_created_total 0\n# TYPE couchdb_couch_replicator_docs_dbs_deleted_total counter\ncouchdb_couch_replicator_docs_dbs_deleted_total 0\n# TYPE couchdb_couch_replicator_docs_dbs_found_total counter\ncouchdb_couch_replicator_docs_dbs_found_total 2\n# TYPE couchdb_couch_replicator_docs_failed_state_updates_total counter\ncouchdb_couch_replicator_docs_failed_state_updates_total 0\n# TYPE couchdb_couch_replicator_failed_starts_total counter\ncouchdb_couch_replicator_failed_starts_total 0\n# TYPE couchdb_couch_replicator_jobs_adds_total counter\ncouchdb_couch_replicator_jobs_adds_total 0\n# TYPE couchdb_couch_replicator_jobs_crashed gauge\ncouchdb_couch_replicator_jobs_crashed 0\n# TYPE couchdb_couch_replicator_jobs_crashes_total counter\ncouchdb_couch_replicator_jobs_crashes_total 0\n# TYPE couchdb_couch_replicator_jobs_duplicate_adds_total counter\ncouchdb_couch_replicator_jobs_duplicate_adds_total 0\n# TYPE couchdb_couch_replicator_jobs_pending gauge\ncouchdb_couch_replicator_jobs_pending 0\n# TYPE couchdb_couch_replicator_jobs_removes_total counter\ncouchdb_couch_replicator_jobs_removes_total 0\n# TYPE couchdb_couch_replicator_jobs_running gauge\ncouchdb_couch_replicator_jobs_running 0\n# TYPE couchdb_couch_replicator_jobs_starts_total counter\ncouchdb_couch_replicator_jobs_starts_total 0\n# TYPE couchdb_couch_replicator_jobs_stops_total counter\ncouchdb_couch_replicator_jobs_stops_total 0\n# TYPE couchdb_couch_replicator_jobs_total gauge\ncouchdb_couch_replicator_jobs_total 0\n# TYPE couchdb_couch_replicator_requests_total counter\ncouchdb_couch_replicator_requests_total 0\n# TYPE couchdb_couch_replicator_responses_failure_total counter\ncouchdb_couch_replicator_responses_failure_total 0\n# TYPE couchdb_couch_replicator_responses_total counter\ncouchdb_couch_replicator_responses_total 0\n# TYPE couchdb_couch_replicator_stream_responses_failure_total counter\ncouchdb_couch_replicator_stream_responses_failure_total 0\n# TYPE couchdb_couch_replicator_stream_responses_total counter\ncouchdb_couch_replicator_stream_responses_total 0\n# TYPE couchdb_couch_replicator_worker_deaths_total counter\ncouchdb_couch_replicator_worker_deaths_total 0\n# TYPE couchdb_couch_replicator_workers_started_total counter\ncouchdb_couch_replicator_workers_started_total 0\n# TYPE couchdb_auth_cache_requests_total counter\ncouchdb_auth_cache_requests_total 0\n# TYPE couchdb_auth_cache_misses_total counter\ncouchdb_auth_cache_misses_total 0\n# TYPE couchdb_collect_results_time_seconds summary\ncouchdb_collect_results_time_seconds{quantile="0.5"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.75"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.9"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.95"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.99"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.999"} 0.0\ncouchdb_collect_results_time_seconds_sum 0.0\ncouchdb_collect_results_time_seconds_count 0\n# TYPE couchdb_couch_server_lru_skip_total counter\ncouchdb_couch_server_lru_skip_total 0\n# TYPE couchdb_database_purges_total counter\ncouchdb_database_purges_total 0\n# TYPE couchdb_database_reads_total counter\ncouchdb_database_reads_total 24\n# TYPE couchdb_database_writes_total counter\ncouchdb_database_writes_total 0\n# TYPE couchdb_db_open_time_seconds summary\ncouchdb_db_open_time_seconds{quantile="0.5"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.75"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.9"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.95"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.99"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.999"} 0.0\ncouchdb_db_open_time_seconds_sum 0.0\ncouchdb_db_open_time_seconds_count 0\n# TYPE couchdb_dbinfo_seconds summary\ncouchdb_dbinfo_seconds{quantile="0.5"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.75"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.9"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.95"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.99"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.999"} 0.0\ncouchdb_dbinfo_seconds_sum 0.0\ncouchdb_dbinfo_seconds_count 0\n# TYPE couchdb_document_inserts_total counter\ncouchdb_document_inserts_total 7\n# TYPE couchdb_document_purges_failure_total counter\ncouchdb_document_purges_failure_total 0\n# TYPE couchdb_document_purges_success_total counter\ncouchdb_document_purges_success_total 0\n# TYPE couchdb_document_purges_total_total counter\ncouchdb_document_purges_total_total 0\n# TYPE couchdb_document_writes_total counter\ncouchdb_document_writes_total 14\n# TYPE couchdb_httpd_aborted_requests_total counter\ncouchdb_httpd_aborted_requests_total 0\n# TYPE couchdb_httpd_all_docs_timeouts_total counter\ncouchdb_httpd_all_docs_timeouts_total 0\n# TYPE couchdb_httpd_bulk_docs_seconds summary\ncouchdb_httpd_bulk_docs_seconds{quantile="0.5"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.75"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.9"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.95"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.99"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.999"} 0.0\ncouchdb_httpd_bulk_docs_seconds_sum 0.0\ncouchdb_httpd_bulk_docs_seconds_count 0\n# TYPE couchdb_httpd_bulk_requests_total counter\ncouchdb_httpd_bulk_requests_total 0\n# TYPE couchdb_httpd_clients_requesting_changes_total counter\ncouchdb_httpd_clients_requesting_changes_total 0\n...">>,...}
extra: []
[error] 2022-06-23T06:23:45.938589Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.23685.4> -------- gen_server couch_prometheus_server terminated with reason: {timeout,{gen_server,call,[couch_stats_aggregator,fetch]}} at gen_server:call/2(line:238) <= couch_stats_aggregator:fetch/0(line:44) <= couch_prometheus_server:get_couchdb_stats/0(line:94) <= couch_prometheus_server:refresh_metrics/0(line:87) <= couch_prometheus_server:handle_info/2(line:74) <= gen_server:try_dispatch/4(line:689) <= gen_server:handle_msg/6(line:765) <= proc_lib:init_p_do_apply/3(line:226)
last msg: redacted
state: {st,<<"# TYPE couchdb_couch_log_requests_total counter\ncouchdb_couch_log_requests_total{level="alert"} 0\ncouchdb_couch_log_requests_total{level="critical"} 0\ncouchdb_couch_log_requests_total{level="debug"} 0\ncouchdb_couch_log_requests_total{level="emergency"} 0\ncouchdb_couch_log_requests_total{level="error"} 0\ncouchdb_couch_log_requests_total{level="info"} 7\ncouchdb_couch_log_requests_total{level="notice"} 18573\ncouchdb_couch_log_requests_total{level="warning"} 0\n# TYPE couchdb_couch_replicator_changes_manager_deaths_total counter\ncouchdb_couch_replicator_changes_manager_deaths_total 0\n# TYPE couchdb_couch_replicator_changes_queue_deaths_total counter\ncouchdb_couch_replicator_changes_queue_deaths_total 0\n# TYPE couchdb_couch_replicator_changes_read_failures_total counter\ncouchdb_couch_replicator_changes_read_failures_total 0\n# TYPE couchdb_couch_replicator_changes_reader_deaths_total counter\ncouchdb_couch_replicator_changes_reader_deaths_total 0\n# TYPE couchdb_couch_replicator_checkpoints_failure_total counter\ncouchdb_couch_replicator_checkpoints_failure_total 0\n# TYPE couchdb_couch_replicator_checkpoints_total counter\ncouchdb_couch_replicator_checkpoints_total 0\n# TYPE couchdb_couch_replicator_cluster_is_stable gauge\ncouchdb_couch_replicator_cluster_is_stable 1\n# TYPE couchdb_couch_replicator_connection_acquires_total counter\ncouchdb_couch_replicator_connection_acquires_total 0\n# TYPE couchdb_couch_replicator_connection_closes_total counter\ncouchdb_couch_replicator_connection_closes_total 0\n# TYPE couchdb_couch_replicator_connection_creates_total counter\ncouchdb_couch_replicator_connection_creates_total 0\n# TYPE couchdb_couch_replicator_connection_owner_crashes_total counter\ncouchdb_couch_replicator_connection_owner_crashes_total 0\n# TYPE couchdb_couch_replicator_connection_releases_total counter\ncouchdb_couch_replicator_connection_releases_total 0\n# TYPE couchdb_couch_replicator_connection_worker_crashes_total counter\ncouchdb_couch_replicator_connection_worker_crashes_total 0\n# TYPE couchdb_couch_replicator_db_scans_total counter\ncouchdb_couch_replicator_db_scans_total 1\n# TYPE couchdb_couch_replicator_docs_completed_state_updates_total counter\ncouchdb_couch_replicator_docs_completed_state_updates_total 0\n# TYPE couchdb_couch_replicator_docs_db_changes_total counter\ncouchdb_couch_replicator_docs_db_changes_total 0\n# TYPE couchdb_couch_replicator_docs_dbs_created_total counter\ncouchdb_couch_replicator_docs_dbs_created_total 0\n# TYPE couchdb_couch_replicator_docs_dbs_deleted_total counter\ncouchdb_couch_replicator_docs_dbs_deleted_total 0\n# TYPE couchdb_couch_replicator_docs_dbs_found_total counter\ncouchdb_couch_replicator_docs_dbs_found_total 2\n# TYPE couchdb_couch_replicator_docs_failed_state_updates_total counter\ncouchdb_couch_replicator_docs_failed_state_updates_total 0\n# TYPE couchdb_couch_replicator_failed_starts_total counter\ncouchdb_couch_replicator_failed_starts_total 0\n# TYPE couchdb_couch_replicator_jobs_adds_total counter\ncouchdb_couch_replicator_jobs_adds_total 0\n# TYPE couchdb_couch_replicator_jobs_crashed gauge\ncouchdb_couch_replicator_jobs_crashed 0\n# TYPE couchdb_couch_replicator_jobs_crashes_total counter\ncouchdb_couch_replicator_jobs_crashes_total 0\n# TYPE couchdb_couch_replicator_jobs_duplicate_adds_total counter\ncouchdb_couch_replicator_jobs_duplicate_adds_total 0\n# TYPE couchdb_couch_replicator_jobs_pending gauge\ncouchdb_couch_replicator_jobs_pending 0\n# TYPE couchdb_couch_replicator_jobs_removes_total counter\ncouchdb_couch_replicator_jobs_removes_total 0\n# TYPE couchdb_couch_replicator_jobs_running gauge\ncouchdb_couch_replicator_jobs_running 0\n# TYPE couchdb_couch_replicator_jobs_starts_total counter\ncouchdb_couch_replicator_jobs_starts_total 0\n# TYPE couchdb_couch_replicator_jobs_stops_total counter\ncouchdb_couch_replicator_jobs_stops_total 0\n# TYPE couchdb_couch_replicator_jobs_total gauge\ncouchdb_couch_replicator_jobs_total 0\n# TYPE couchdb_couch_replicator_requests_total counter\ncouchdb_couch_replicator_requests_total 0\n# TYPE couchdb_couch_replicator_responses_failure_total counter\ncouchdb_couch_replicator_responses_failure_total 0\n# TYPE couchdb_couch_replicator_responses_total counter\ncouchdb_couch_replicator_responses_total 0\n# TYPE couchdb_couch_replicator_stream_responses_failure_total counter\ncouchdb_couch_replicator_stream_responses_failure_total 0\n# TYPE couchdb_couch_replicator_stream_responses_total counter\ncouchdb_couch_replicator_stream_responses_total 0\n# TYPE couchdb_couch_replicator_worker_deaths_total counter\ncouchdb_couch_replicator_worker_deaths_total 0\n# TYPE couchdb_couch_replicator_workers_started_total counter\ncouchdb_couch_replicator_workers_started_total 0\n# TYPE couchdb_auth_cache_requests_total counter\ncouchdb_auth_cache_requests_total 0\n# TYPE couchdb_auth_cache_misses_total counter\ncouchdb_auth_cache_misses_total 0\n# TYPE couchdb_collect_results_time_seconds summary\ncouchdb_collect_results_time_seconds{quantile="0.5"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.75"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.9"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.95"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.99"} 0.0\ncouchdb_collect_results_time_seconds{quantile="0.999"} 0.0\ncouchdb_collect_results_time_seconds_sum 0.0\ncouchdb_collect_results_time_seconds_count 0\n# TYPE couchdb_couch_server_lru_skip_total counter\ncouchdb_couch_server_lru_skip_total 0\n# TYPE couchdb_database_purges_total counter\ncouchdb_database_purges_total 0\n# TYPE couchdb_database_reads_total counter\ncouchdb_database_reads_total 24\n# TYPE couchdb_database_writes_total counter\ncouchdb_database_writes_total 0\n# TYPE couchdb_db_open_time_seconds summary\ncouchdb_db_open_time_seconds{quantile="0.5"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.75"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.9"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.95"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.99"} 0.0\ncouchdb_db_open_time_seconds{quantile="0.999"} 0.0\ncouchdb_db_open_time_seconds_sum 0.0\ncouchdb_db_open_time_seconds_count 0\n# TYPE couchdb_dbinfo_seconds summary\ncouchdb_dbinfo_seconds{quantile="0.5"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.75"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.9"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.95"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.99"} 0.0\ncouchdb_dbinfo_seconds{quantile="0.999"} 0.0\ncouchdb_dbinfo_seconds_sum 0.0\ncouchdb_dbinfo_seconds_count 0\n# TYPE couchdb_document_inserts_total counter\ncouchdb_document_inserts_total 7\n# TYPE couchdb_document_purges_failure_total counter\ncouchdb_document_purges_failure_total 0\n# TYPE couchdb_document_purges_success_total counter\ncouchdb_document_purges_success_total 0\n# TYPE couchdb_document_purges_total_total counter\ncouchdb_document_purges_total_total 0\n# TYPE couchdb_document_writes_total counter\ncouchdb_document_writes_total 14\n# TYPE couchdb_httpd_aborted_requests_total counter\ncouchdb_httpd_aborted_requests_total 0\n# TYPE couchdb_httpd_all_docs_timeouts_total counter\ncouchdb_httpd_all_docs_timeouts_total 0\n# TYPE couchdb_httpd_bulk_docs_seconds summary\ncouchdb_httpd_bulk_docs_seconds{quantile="0.5"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.75"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.9"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.95"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.99"} 0.0\ncouchdb_httpd_bulk_docs_seconds{quantile="0.999"} 0.0\ncouchdb_httpd_bulk_docs_seconds_sum 0.0\ncouchdb_httpd_bulk_docs_seconds_count 0\n# TYPE couchdb_httpd_bulk_requests_total counter\ncouchdb_httpd_bulk_requests_total 0\n# TYPE couchdb_httpd_clients_requesting_changes_total counter\ncouchdb_httpd_clients_requesting_changes_total 0\n...">>,...}
extra: []
[error] 2022-06-23T06:23:45.953809Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.23685.4> -------- CRASH REPORT Process couch_prometheus_server (<0.23685.4>) with 0 neighbors exited with reason: {timeout,{gen_server,call,[couch_stats_aggregator,fetch]}} at gen_server:call/2(line:238) <= couch_stats_aggregator:fetch/0(line:44) <= couch_prometheus_server:get_couchdb_stats/0(line:94) <= couch_prometheus_server:refresh_metrics/0(line:87) <= couch_prometheus_server:handle_info/2(line:74) <= gen_server:try_dispatch/4(line:689) <= gen_server:handle_msg/6(line:765) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_prometheus_server,init,['Argument__1']}, ancestors: [couch_prometheus_sup,<0.251.0>], message_queue_len: 1, links: [<0.252.0>], dictionary: [], trap_exit: false, status: running, heap_size: 46422, stack_size: 28, reductions: 5547311068
[error] 2022-06-23T06:23:45.954202Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.23685.4> -------- CRASH REPORT Process couch_prometheus_server (<0.23685.4>) with 0 neighbors exited with reason: {timeout,{gen_server,call,[couch_stats_aggregator,fetch]}} at gen_server:call/2(line:238) <= couch_stats_aggregator:fetch/0(line:44) <= couch_prometheus_server:get_couchdb_stats/0(line:94) <= couch_prometheus_server:refresh_metrics/0(line:87) <= couch_prometheus_server:handle_info/2(line:74) <= gen_server:try_dispatch/4(line:689) <= gen_server:handle_msg/6(line:765) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_prometheus_server,init,['Argument__1']}, ancestors: [couch_prometheus_sup,<0.251.0>], message_queue_len: 1, links: [<0.252.0>], dictionary: [], trap_exit: false, status: running, heap_size: 46422, stack_size: 28, reductions: 5547311068
[error] 2022-06-23T06:23:46.044832Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.252.0> -------- Supervisor couch_prometheus_sup had child couch_prometheus_server started with couch_prometheus_server:start_link() at <0.23685.4> exit with reason {timeout,{gen_server,call,[couch_stats_aggregator,fetch]}} in context child_terminated
[error] 2022-06-23T06:23:46.044957Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.252.0> -------- Supervisor couch_prometheus_sup had child couch_prometheus_server started with couch_prometheus_server:start_link() at <0.23685.4> exit with reason {timeout,{gen_server,call,[couch_stats_aggregator,fetch]}} in context child_terminated
[notice] 2022-06-23T06:23:46.364711Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30722.22> 4688407aa4 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 49
[notice] 2022-06-23T06:24:06.671559Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30883.22> 54b4dc40cb 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 150
[notice] 2022-06-23T06:24:09.260972Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30884.22> e34d093bcd 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 1660
[info] 2022-06-23T06:24:09.602627Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.40.0> -------- SIGTERM received - shutting down
[info] 2022-06-23T06:24:09.602724Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.40.0> -------- SIGTERM received - shutting down
[notice] 2022-06-23T06:24:14.600448Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.30916.22> c6896d1f00 192.168.230.108:5984 10.1.2.179 undefined GET /_up 200 ok 56
[error] 2022-06-23T06:24:18.961753Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.811.0> -------- gen_server <0.811.0> terminated with reason: killed
last msg: redacted
state: {state,#Ref<0.3717146181.405405699.170850>,couch_replicator_doc_processor,nil,<<"_replicator">>,#Ref<0.3717146181.405274627.170851>,nil,[],true}
extra: []
[error] 2022-06-23T06:24:18.962005Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.811.0> -------- gen_server <0.811.0> terminated with reason: killed
last msg: redacted
state: {state,#Ref<0.3717146181.405405699.170850>,couch_replicator_doc_processor,nil,<<"_replicator">>,#Ref<0.3717146181.405274627.170851>,nil,[],true}
extra: []
[error] 2022-06-23T06:24:18.962362Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.811.0> -------- CRASH REPORT Process (<0.811.0>) with 0 neighbors exited with reason: killed at gen_server:decode_msg/9(line:475) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_multidb_changes,init,['Argument__1']}, ancestors: [<0.692.0>,couch_replicator_sup,<0.668.0>], message_queue_len: 0, links: [], dictionary: [], trap_exit: true, status: running, heap_size: 1598, stack_size: 28, reductions: 181192
[error] 2022-06-23T06:24:19.005925Z couchdb@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local <0.811.0> -------- CRASH REPORT Process (<0.811.0>) with 0 neighbors exited with reason: killed at gen_server:decode_msg/9(line:475) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_multidb_changes,init,['Argument__1']}, ancestors: [<0.692.0>,couch_replicator_sup,<0.668.0>], message_queue_len: 0, links: [], dictionary: [], trap_exit: true, status: running, heap_size: 1598, stack_size: 28, reductions: 181192`
Version of Helm and Kubernetes:
Helm Version: 3.4.0
Kubernetes Version: 1.18.3
What happened:
The coordinator pod would routinely restart due to the error shown above in the logs
What you expected to happen:
All pods should remain running without restarting
How to reproduce it (as minimally and precisely as possible):
The issue occurs randomly and restarts with the error shown in the logs.
Anything else we need to know:
We have the helm chart deployed in both a testing a production kubernetes environment and both environments demonstrate the same behaviour. The db only has a small amount of data in it and the pods do not have any cpu or memory restrictions. The pods are configured with 16Gb local-path PV's. Average memory usage is 56Mb and cpu usage below 0.03
Describe the bug
I can't get couch_peruser config setting to work I'm hoping it's something simple I'm missing happens a lot ha
Version of Helm and Kubernetes:
minikube version: v1.5.2
helm version
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}
What happened:
when i make a new user in _users db it is not auto creating a db for that user
What you expected to happen:
auto creating a db for that user
How to reproduce it (as minimally and precisely as possible):
This was my install steps. I also put ingress controller ip in my hosts file to chart-example.local
once I was through the steps I opened
http://chart-example.local/_utils in browser
helm repo add couchdb https://apache.github.io/couchdb-helm
kubectl create secret generic couchv1-couchdb --from-literal=adminUsername=travis --from-literal=adminPassword=testPass12 --from-literal=cookieAuthSecret=testPass12secret
helm install couchv1 \
couchdb/couchdb \
--set createAdminSecret=false \
--set clusterSize=3 \
--set ingress.enabled=true \
--set persistentVolume.enabled=true \
--set couch_peruser.enable=true \ // i tried this
--set couchdbConfig.couch_peruser.enable=true \ . // i tried this and i tried both
--set couchdbConfig.couchdb.uuid=decafbaddecafbaddecafbaddecafbad
curl -X POST -H "Content-Type: application/json" http://travis:[email protected]/_cluster_setup -d '{"action": "finish_cluster"}'
Anything else we need to know:
I'm a noob I tried to access the pods couch config file to see what in it for settings but I could not find a way to open or edit the file.
if i run with both couch_peruser in diff spots i get this
Helm get values couchv1
USER-SUPPLIED VALUES:
clusterSize: 3
couch_peruser:
enable: true
couchdbConfig:
couch_peruser:
enable: true
couchdb:
uuid: decafbaddecafbaddecafbaddecafbad
createAdminSecret: false
ingress:
enabled: true
persistentVolume:
enabled: true
this is a user doc that should trigger a new user db when inserted into _users db
well thats it does on my single node install maybe cluster is different?
{
"_id": "org.couchdb.user:DavidWonderman7",
"_rev": "1-853d92e2cfe8fb10bb323e967c09c704",
"name": "DavidWonderman7",
"roles": [
"basic"
],
"type": "user",
"password_scheme": "pbkdf2",
"iterations": 10,
"derived_key": "35a0d27874ce314f992ea4918cab8350e9bd99c2",
"salt": "8e5d888eb4f23277c621d8efc3ad8318"
}
Describe the bug
Hi,
I am deploying the couchdb over IBM kubernetes cluster using the helm chart, all the things are fine except pod is crashing, I have tried to debug doesn't find any relevant clue
Version of Helm and Kubernetes:
**Helm Version **
Client: &version.Version{SemVer:"v2.14.3",
Server: &version.Version{SemVer:"v2.14.3",
K8s version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.8",
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.12+IKS", ____________________________________________________________________________________________
What happened:
node.kubernetes.io/unreachable:NoExecute for 600s
Events:
Type Reason Age From Message
Normal Scheduled 22m default-scheduler Successfully assigned default/testcouch-couchdb-0 to
Normal Pulling 22m kubelet, pulling image "busybox:latest"
Normal Pulled 22m kubelet, Successfully pulled image "busybox:latest"
Normal Created 22m kubelet Created container
Normal Started 22m kubelet, Started container
Normal Pulled 21m (x4 over 22m) kubelet, Container image "couchdb:2.3.1" already present on machine
Normal Created 21m (x4 over 22m) kubelet, Created container
Normal Started 21m (x4 over 22m) kubelet, Started container
Warning BackOff 118s (x98 over 21m) kubelet, Back-off restarting failed container
https://cloud.ibm.com/kubernetes/helm/ibm-charts/couchdb
Regards,
Vedansh
Is your feature request related to a problem? Please describe.
When draining a Kubernetes node with kubectl drain
, several couchdb pods are sometimes evicted at the same time, resulting in an unavailable couchdb cluster.
Describe the solution you'd like
Adding a kind: PodDisruptionBudget
option to allow for drain to respect the disruption budget. For example waiting for the first evicted pod to be ready before evicting the next one.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Smaller kubernetes clusters are more affected by this since there are more chances that 2 couchdb pods are scheduled on the same node.
Here is an example of values that this could be controlled with:
podDisruptionBudget:
enabled: false
# minAvailable: 1
maxUnavailable: 1
We often have Pull Requests that could be merged but are missing the make publish
step. At a minimum we can check for that as part of the PR validation.
Describe the bug
The couchdb
chart generates two services. The ingress generated by the chart points at the headless service, which is suspected to be a bug since the headless service is defined for the purposes of statefulset maintenance. The client service's niceties (i.e. setting annotations) cannot be used as expected because of this bug.
Tangentially related to #69 , since ingress class can also be set by service annotations in some cases
Version of Helm and Kubernetes: N/A
What happened:
Cannot set annotations on the ingress's service
What you expected to happen:
Set annotations on the ingress's service
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
Describe the bug
The latest Chart in the chart repo is 3.3.4 & it seems the current index.yaml has been created 2020-07-20
See also: https://github.com/apache/couchdb-helm/deployments/activity_log?environment=github-pages
What you expected to happen:
Me want 3.6.0 :(
How to reproduce it (as minimally and precisely as possible):
404: https://apache.github.io/couchdb-helm/couchdb-3.6.0.tgz
https://apache.github.io/couchdb-helm/index.yaml
Anything else we need to know:
The CouchDB Dockerfiles lay down an [admins]
section in /opt/couchdb/etc/local.d/docker.ini
here. The Helm chart is currently configured such that /opt/couchdb/etc/default.d
is persistent but /opt/couchdb/etc/local.d
is not.
This results in regeneration of the admin hashes whenever a CouchDB pod is restarted, invalidating any session cookies and leading to inconsistent auth failures with cookies are used.
I think the safest thing is likely to just make /opt/couchdb/etc/local.d
persistent as well; the Dockerfile will already skip laying down a new [admins]
section if one is present.
cc @kocolosk
Describe the bug
It looks like the GH pages setup for couchdb-helm is still pointing to the master
branch, while the latest version of the chart is being deployed to the main
branch. In order to complete the transition from master
->main
, .asf.yaml
should be updated and/or the branch in this repo's [Settings -> Pages -> Source] option should be changed to point to the main
branch. It may also be helpful to delete the master branch to reduce future confusion.
Version of Helm and Kubernetes:
Helm 3.7.2
What happened:
Followed README for setting up couchdb Helm repo, and found couchdb-helm v3.3.4 and couchdb 3.1.0 installed per master's index.yaml.
What you expected to happen:
Expected couchdb-helm 3.4.0 and couchdb 3.2.0 to be installed per main's index.yaml.
How to reproduce it (as minimally and precisely as possible):
Follow installation instructions in couchdb-helm README
Anything else we need to know:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.