Open v1nsai opened 6 months ago
you use the wrong values for setup to work with an existing/externalDatabase.
you need to use externalDatabase.existingSecret
instatt of mariadb.auth.existingSecret
.
PS: a look in your secret ... i thing you need also to set also externalDatabase.existingSecret.passwordKey=...
After checking the definition of the templates, I confirm what @wrenix said.
It turns out that externalDatabase.existingSecret
must be used to specify the same secret the dependency-db-chart uses, otherwise the variables will be used.
After checking the definition of the templates, I confirm what @wrenix said.
It turns out that
externalDatabase.existingSecret
must be used to specify the same secret the dependency-db-chart uses, otherwise the variables will be used.
Also just confirmed this bug as well. I ran into the same issue as @wrenix and when reviewing the templates came to the same conclusion that their is a bug in the helm charts.
I do not see any bug here, that is an expected behaviour.
Option 1: you use the internalDatabase with the dependencies of an mariadb Option 2: you use another database, so you could use externalDatabase
but here in this issue the person disabled the internalDatabase / depenencies mariadb-chart and wonder, that the have to use externalDatabase.existingSecret
instatt of mariadb.auth.existingSecret
If you use the mariadb.authexistingSecret this failure happens while using the mariadb.enabled. The workaround is to set the externalDatabase.existingSecret even though you are NOT enabling externalDatabase since you are using mariadb. This is very much a bug.
Here is the issue, notice how mariadb.auth.existingSecret is not referenced at all.
{{- if .Values.mariadb.enabled }}
- name: mariadb-isalive
image: {{ .Values.mariadb.image.registry | default "docker.io" }}/{{ .Values.mariadb.image.repository }}:{{ .Values.mariadb.image.tag }}
env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: {{ .Values.externalDatabase.existingSecret.secretName | default (printf "%s-db" .Release.Name) }}
key: {{ .Values.externalDatabase.existingSecret.usernameKey }}
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: {{ .Values.externalDatabase.existingSecret.secretName | default (printf "%s-db" .Release.Name) }}
key: {{ .Values.externalDatabase.existingSecret.passwordKey }}
'''
@hagak okay i understand your bug -> but that is a different "bug" like @v1nsai describt.
@v1nsai values is
mariadb:
enabled: true
existingSecret: ".."
internalDatabase:
enabled: false
externalDatabase:
enabled: true
@hagak values is
mariadb:
enabled: true
auth:
existingSecret: ".."
and you are correct, that product a bug in several places
Thanks for the hints @wrenix , I understand the problem now. I wasn't configuring how to connect to the "external" database in the externalDatabase
config. I got it working by adding those connection details for externalDatabase
and not messing with internalDatabase
at all:
externalDatabase:
enabled: true
existingSecret:
enabled: true
secretName: mariadb-passwords
usernameKey: mariadb-username
passwordKey: mariadb-password
mariadb:
enabled: true
auth:
existingSecret: mariadb-passwords
Describe your Issue
When using an existing secret with the bitnami mariadb chart config, nextcloud pod is unable to log into mariadb. The existing secret contains the keys specified in the
values.yaml
file. When omittingmariadb.existingSecret
, the pod starts up no problem.Logs and Errors
Describe your Environment
Kubernetes distribution: MicroK8s v1.28.3 revision 6089
Helm Version (or App that manages helm): Microk8s Helm version.BuildInfo{Version:"v3.9.1+unreleased", GitCommit:"6303a77a1c2a0be76eaec96531e0a99bddec959a", GitTreeState:"clean", GoVersion:"go1.20.10"}
Helm Chart Version: latest
values.yaml
: N/A because I am avoiding using a separatevalues.yaml
for simplicity and always using the latest. Here's my helm command:Additional context, if any
I've checked 1000 times to make sure that I'm including the proper keys in the
mariadb-passwords
secret, this looks correct to meI created all of the passwords with
openssl rand -base64 20
, if that makes any difference