Openldap config: fix #40

[jeanpommier]

• read the configuration from chart's values file(s)
• support passing the password (and possibly other env var alongside) using a secret

Example of valid secret could be

apiVersion: v1
kind: Secret
metadata:
  name: myldapsecret
type: Opaque
data:
  SLAPD_PASSWORD: "bXlzZWNyZXRsZGFwYWRtaW5wYXNzd29yZA=="

where the value is the actual password base64 encoded (echo -n 'mysecretldapadminpassword' | base64)

[edevosc2c]

Thank you for the PR, one remark is that I much prefer to do like it's already possible for database credentials.

Create a Kubernetes Secret anyway if the user doesn't pass one: https://github.com/georchestra/helm-georchestra/blob/main/templates/database/database-geodata-secret.yaml

Instead of having the ability to pass a Kubernetes Secret, but still allow the ability to pass the password through an environment variable.

By the way, this time the CI is throwing a real error 😄: https://github.com/georchestra/helm-georchestra/actions/runs/6000210528/job/16271828142?pr=47#step:7:34
(I did fix the CI so now it should throw real errors if they are detected)

[jeanpommier]

I much prefer to do like it's already possible for database credentials

Okay, I can update it accordingly. Are you fine with using the

envFrom:
         - secretRef:

syntax anyway ?

[jeanpommier]

Is this better ?

[jeanmi151]

Maybe add a note that it can NOT be changed just by changing the value of the secret !!!

[jeanpommier]

Yep, you're right. I'm reformulating.

[edevosc2c]

Good for me but I think one day we should document the structure of each secret :).

[edevosc2c]

can't this be refactored with a "default" function from helm?
similar to

helm-georchestra/templates/_helpers.tpl

Line 5 in 41289ec

{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}

[jeanpommier]

Quite possibly. I must admit I merely copied the logic from https://github.com/georchestra/helm-georchestra/blob/main/templates/_helpers.tpl#L71

[jeanpommier]

OK, it should be better now

[jeanpommier]

Good for me but I think one day we should document the structure of each secret :).

You mean you'd rather have it more explictly loading just the one environment variable ? It's fine by me too

[edevosc2c]

Good for me but I think one day we should document the structure of each secret :).

You mean you'd rather have it more explictly loading just the one environment variable ? It's fine by me too

No, I mean there are a lot of other cases where we allow an external secret but it's undocumented.

[edevosc2c]

good for me, waiting on the CI to pass

[jeanpommier]

CI failure doesn't seem related to this PR, right @edevosc2c ?

[edevosc2c]

mmh that seems like a CI breaking again, that's odd I did my best to get it working properly. I have re-run it in case it would pass again during the night.

I'll check again tomorrow.