Fresh 3 Nodes cluster do not pass Fauxton GUI replica check.

[urbaman]

Describe the bug Did a fresh setup:

helm repo add couchdb https://apache.github.io/couchdb-helm helm repo update helm install couchdb couchdb/couchdb --set persistentVolume.enabled=true --set couchdbConfig.chttpd.require_valid_user=true --set prometheusPort.enabled=true --set couchdbConfig.couchdb.uuid= --namespace couchdb --create-namespace

The cluster responds, and I can connect to single pods from una of the pods:

root@couchdb-couchdb-0:/# curl http://admin:password@couchdb-couchdb.couchdb.svc.cluster.local:5984/
{"couchdb":"Welcome","version":"3.3.2","git_sha":"11a234070","uuid":"90486a5d-b089-4356-8c1a-4f99fe63cb13","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

root@couchdb-couchdb-0:/# curl http://admin:password@couchdb-couchdb-0.couchdb-couchdb.couchdb.svc.cluster.local:5984/
{"couchdb":"Welcome","version":"3.3.2","git_sha":"11a234070","uuid":"90486a5d-b089-4356-8c1a-4f99fe63cb13","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

root@couchdb-couchdb-0:/# curl http://admin:password@couchdb-couchdb-2.couchdb-couchdb.couchdb.svc.cluster.local:5984/
{"couchdb":"Welcome","version":"3.3.2","git_sha":"11a234070","uuid":"90486a5d-b089-4356-8c1a-4f99fe63cb13","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

root@couchdb-couchdb-0:/# curl http://admin:password@couchdb-couchdb-1.couchdb-couchdb.couchdb.svc.cluster.local:5984/
{"couchdb":"Welcome","version":"3.3.2","git_sha":"11a234070","uuid":"90486a5d-b089-4356-8c1a-4f99fe63cb13","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

If I check up the cluster from the Fauxton GUI, all of the checks are good but the last one (replication), with the following error: couchdb cluster Error: {session request failed,http://any:5984/_session,admin, {conn_failed,{error,nxdomain}}}

Is there anything I could check or setup to make it work properly?

Version of Helm and Kubernetes:

Helm 3.10.1 Kubernetes 1.28.1

What happened:

As seen above, the Fauxton GUI cluster check fails on the last check (replication)

What you expected to happen:

The check to be passed

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

Install, undergo the cluster checkup trhough Fauxton GUI

Anything else we need to know:

[urbaman]

Update:

Connecting to the single node's Fauxton GUI, and doing a manaul check (connect to node 1, create db, connect to node 2, check db presence), the replication seems to work properly, only the Fauxton GUI's checkup fails on the last check.

[willholley]

@urbaman what URL are you using to access Fauxton and is it routable from the CouchDB pods?

[urbaman]

Hi,

It's behind a proxy (traefik), on couchdb service port 5984. I have the same exact problem if I reach the GUI via kubectl port-forward -n couchdb service/couchdb-couchdb 5984

[willholley]

broadly, I think the issue is that all replications in CouchDB are "remote" i.e. require the source and target databases to be fully qualified domain names that are routable from each CouchDB pod.

Fauxton's replication check does not populate a FQDN, I believe, and relies on CouchDB's legacy (pre-clustering) behaviour:

For backwards compatibility, CouchDB 3.x will auto-convert bare database names by prepending the address and port CouchDB is listening on, to form a complete URL. This behaviour is deprecated in 3.x and will be removed in CouchDB 4.0.

The CouchDB bind address comes from the following in the Helm chart values.yaml:

couchdbConfig:
  chttpd:
    bind_address: any

so perhaps you could change it to 127.0.0.1 instead, if you care about the check passing.

Otherwise, you can just ignore the check given "real" replications would go through the front-end Kube service anyway.

[urbaman]

Hi, sorry for being late in answering.

So, the three couchdb instances are actually replicated between them, even if the GUI check fails?

Thank you.