apache/couchdb-helm

Apache CouchDB Helm Chart

CouchDB Helm Charts

This repository contains assets related to the CouchDB Helm chart.

Layout

• couchdb: contains the unbundled Helm chart
• test: containes scripts to test the chart locally using Kind

Testing

make test will run an integration test using Kind. This stands up a Kubernetes cluster locally and ensures the chart will deploy using the default options and Helm.

On GitHub, there is a GitHub Action to Lint and Test charts for each PR.

Releasing

On merge to main, a new release is generated by the Chart Releaser GitHub action.

Feedback / Issues / Contributing

General feedback is welcome at our user or developer mailing lists.

Apache CouchDB has a CONTRIBUTING file with details on how to get started with issue reporting or contributing to the upkeep of this project. In short, use GitHub Issues, do not report anything to the Helm team.

The chart follows the technical guidelines / best practices maintained by the Helm team.

couchdb-helm's Issues

Breaking change from Version 3.6.0 -> 3.6.1

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):

• take default values.yaml for version 3.6.0
• set cluster size to min 2
• deploy 3.6.0
• upgrade version to 3.6.1

Anything else we need to know:
Workaround:
Add erlang flags section into values.yaml

erlangFlags:
  name: couchdb
  setcookie: monster

does couch_peruser work?

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"
}

Add `extraObjects` value that allows creating supportive / adhoc resources

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:

• deploying the secret
• supportive prometheus, certificate, etc. deployment

Our implementation:
https://github.com/rstudio/helm/blob/ac2ad2b2e3c84309a456f6229934e5170c82164e/charts/rstudio-library/templates/_tplvalues.tpl#L6-L14

https://github.com/rstudio/helm/blob/ac2ad2b2e3c84309a456f6229934e5170c82164e/charts/rstudio-connect/templates/extra-objects.yaml#L1-L4

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

Erlang cookie not the same on all nodes

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:

• adminUsername: admin
• adminPassword: myPassword
• cookieAuthSecret: mySecret
• erlangCookie: 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: {}

Automate generation of README values documentation

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
  • Unfortunately, if this is desirable, the workaround is a little gross in the short term. I am happy to PR for review based on preference of output
  • An example display of "all values in a big table together" is here
• Currently the documentation in 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?

Update Installation Guide

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

Pods gets crashing if you have deny-all network policy in place

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:

• Chart has ingress settings for couch pod - pod communication but does not have egress allowed
• Readiness and liveness probe fails because kube-dns can not communicate. (because of the deny-all policy)

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

`make test` fails

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:

• Debian 10.5
• docker-ce version 18.06.3~ce
• kind v0.8.1 go1.15 linux/amd64

What 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):

1. Install kind (GO111MODULE="on" go get sigs.k8s.io/[email protected] && kind create cluster)
2. Run 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.

(Optionally) run _cluster_setup after installation

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.

Warning during install: Skipped value for affinity: Not a table

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

affinity:

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.

query server config

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?

Feature Request: Helm chart for CouchDB version 3.0.0 and/or 3.1.0.

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.

couchdb pod is crashing with any relevant clue

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

Support IngressClass

Hi,

would it be possible to support setting a IngressClass?

Thanks
Regards,
Kilian

Idempotent Helm chart install action?

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

What is the problem?

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.

Ideas for improvements on CouchDB helm chart

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.

Workaround

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

Support for custom Pod labels?

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.

Add podDisruptionBudget.enabled value

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

A value for couchdbConfig.couchdb.uuid must be set

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

https://apache.github.io/couchdb-helm is not there

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

setting annotation would fail the installation for chart version above 3.3.0

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.

Make persistent secret generation for `adminSecret`

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.

post-install job uses hard-coded cluster.local DNS suffix

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).

Anything else we need to know:

unable to setup couch db on ipv6 only environemnt.

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

Cluster setup wizards does not work in microk8s

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.

Add ability to add node selector

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

Gitlab Pages / Helm Repo broken

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:

Fix broken CI on main

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:

Add a NOTES.txt message for adminHash and adminPassword both being set

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

Figure out a way to avoid manual action after deploying a cluster with the helm chart

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

	Once all of the Pods are fully Ready, execute the following command to create
	some required system databases:
	kubectl exec --namespace {{ .Release.Namespace }} {{ if not .Values.allowAdminParty }}-it {{ end }}{{ template "couchdb.fullname" . }}-0 -c couchdb -- \

no loadbalancerIP for service

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 }}

Translate smoke test to GH Action

It would be useful to automatically run the chart install test defined in e2e-kind.sh when a PR is submitted.

Couchdb pods perpetually crashing under OpenShift

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):

1. Install OpenShift Origin 3.11
2. Setup other cluster/namespace prerequisites, e.g. create the namespace as used in the example above.
3. Install the CouchDB helm chart, as above

Anything else we need to know:

Problem with enableSearch=True (Could not connect to the Clouseau Java service)

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 [e-mail] <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?

Configurable Ingress Path

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.

helm chart default install de-facto doesn't work (inconsistent adminHash)

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)

The CouchDB Helm chart has an issue

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 }}

Cluster auto-scaling best practices

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

Container couchdb is going into restart loop right after deploy without any logs

Describe the bug

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:

Kubernetes

Provider: Amazon EKS, Kubernetes Version: v1.24.13 -0a21954

Helm:

version.BuildInfo{Version:"v3.9.4", GitCommit:"dbc6d8e20fe1d58d50e6ed30f09a04a77e4c68db", GitTreeState:"clean", GoVersion:"go1.17.13"}

StorageClass:

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

What happened:

The StatefulSet is unable to start with Amzon EFS Persistence Storage

How to reproduce it (as minimally and precisely as possible):

Create EFS Storage on EKS and deploy following the guide in the README.

Anything else we need to know:

values.yaml

# -- 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

kubectl describe pod couchdb-couchdb-0 -n couchdb-qa

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

kubectl logs couchdb-qa-couchdb-0 -n couchdb-qa

Defaulted container "couchdb" out of: couchdb, init-copy (init)

kubectl logs couchdb-qa-couchdb-0 --container init-copy -n couchdb-qa

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

Run checks for chart version metadata update as GH Action

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.

admin hashes get regenerated on pod restart

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

RFC: Is this project still maintained? Fork needed?

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.

Wrong use of `.Values` in ingress

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

Coordinator node regularly restarts in 3 node cluster

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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <0.40.0> -------- SIGTERM received - shutting down

[info] 2022-06-23T06:24:09.602724Z [e-mail] <0.40.0> -------- SIGTERM received - shutting down

[notice] 2022-06-23T06:24:14.600448Z [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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 [e-mail] <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

Fauxton shows “This database failed to load” after pod restarts

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:

annotations:

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

Changed auto-generated erlang cookie causes cluster restart issues

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)

Add Jenkins integration

#1 adds chart testing using KinD. It should be possible to run these as a CI check in Jenkins, assuming we can get this repository hooked up.

Is there more to it than just adding a Jenkinsfile?

[ENH] - Provide a liveliness check for storage

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.

Update GH pages to point to main branch

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:

Ingress should point to the "not headless" service

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):

couchdb-helm/couchdb/templates/ingress.yaml

Line 2 in 78eff8c

{{- $serviceName := include "couchdb.fullname" . -}}

couchdb-helm/couchdb/templates/headless.yaml

Line 4 in 78eff8c

name: {{ template "couchdb.fullname" . }}

couchdb-helm/couchdb/templates/service.yaml

Line 5 in 78eff8c

name: {{ template "couchdb.svcname" . }}

Anything else we need to know:

Make clear in the docs how to customize authentication

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:

• add to documentation a note about configuring authentication and what the effects can be. Not 100% sure I would have caught this there, but it would have been helpful in hindsight at least.
• warn in NOTES.txt if these values are changed in such a way that successful auth is unlikely
• add more escape hatches on the readinessProbe so that someone can override the defaults if they would like
• Am I right that require_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.