Incorrect hard-coded database host when using Bitnami subcharts
Nobody has claimed this yet.
- Dominant language
- Go Template
- Stars
- 534
- Forks
- 314
- Avg merge
- 42m
- Merged PRs (30d)
- 1
Description
Describe your Issue
When using an external database, if either of the Bitnami subcharts for MariaDB or PostgreSQL are set up in replication mode, the Nextcloud init container will fail because it's using a hard-coded DB hostname value: --host=%s-mariadb or -h %s-postgresql. Neither of these take into account the fact that if you enable replication on the Bitnami MariaDB chart, for example, it creates service names nextcloud-mariadb-primary and nextcloud-mariadb-secondary, but no nextcloud-mariadb, as expected by the mariadb-isalive container.
Logs and Errors
The mariadb-isalive container in the nextcloud-* pods get stuck with these logs repeating ad infinitum:
ERROR 2005 (HY000): Unknown server host 'nextcloud-mariadb' (-2)
waiting for mysql
Describe your Environment
-
Kubernetes distribution: confirmed on both EKS and baremetal
-
Helm Version (or App that manages helm): ArgoCD v2.7.3 running Helm v3.11.2 (EKS) and Helm v3.12.0 (baremetal)
-
Helm Chart Version: 3.5.13
-
values.yaml:
# --------------------------------------------------------------------------- #
# Nextcloud #
# --------------------------------------------------------------------------- #
nextcloud:
host: nextcloud.[REDACTED]
existingSecret:
enabled: true
secretName: nextcloud-secrets
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
securityContext:
runAsUser: 1020
runAsGroup: 1005
runAsNonRoot: true
# --------------------------------------------------------------------------- #
# Database #
# --------------------------------------------------------------------------- #
internalDatabase:
enabled: false
externalDatabase:
enabled: true
type: mysql
host: nextcloud-mariadb-primary
database: nextcloud
existingSecret:
secretName: nextcloud-secrets
usernameKey: mariadb-username
passwordKey: mariadb-password
mariadb:
enabled: true
auth:
database: nextcloud
username: nextcloud
existingSecret: nextcloud-secrets
architecture: replication
primary:
persistence:
enabled: true
existingClaim: nextcloud-mariadb-persistence
storageClass: ceph-block
accessMode: ReadWriteOnce
size: 8Gi
# --------------------------------------------------------------------------- #
# Redis #
# --------------------------------------------------------------------------- #
redis:
enabled: true
clusterDomain: [REDACTED (NON-DEFAULT)]
auth:
enabled: true
existingSecret: nextcloud-secrets
existingSecretPasswordKey: redis-password
# --------------------------------------------------------------------------- #
# Resources #
# --------------------------------------------------------------------------- #
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1000m
memory: 2Gi
# --------------------------------------------------------------------------- #
Additional context, if any
I did set the value of externalDatabase.host to the correct service name nextcloud-mariadb-primary, but this still fails because these lines in _helpers.tpl are overwriting it:
76 {{- else if .Values.mariadb.enabled }}
77 - name: MYSQL_HOST
78 value: {{ template "mariadb.primary.fullname" .Subcharts.mariadb }}
...
126 {{- else }}
127 - name: MYSQL_HOST
128 value: {{ .Values.externalDatabase.host | quote }}
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in charts/nextcloud/templates/_helpers.tpl around lines 76-128, where MYSQL_HOST is selected, and compare the generated environment with the externalDatabase.host value in the reported values.yaml. Use Helm rendering with MariaDB and PostgreSQL replication enabled; done means the init container uses an available replication service hostname instead of the nonexistent hard-coded base name.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes, mariadb, postgresql
- Domain
- databases, devops
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100