updated `keycloak.postgresql.fullname` is wrong when chart is used as subchart

[lmsurpre]

Firstly, thanks for maintaining this high-quality keycloak chart. Recently, I tried upgrading from 18.1.1 to 18.3.0 (since 18.1.1 references a bitnami postgresql chart that no longer seems to exist).

Unfortunately, one of the recent changes in this chart is giving me some trouble.

Here is the current structure of our chart:

• my chart
  • my postgres subchart
  • keycloak subchart
    • keycloak postgres subchart

Although they both use the bitnami postgresql chart, I chose to keep the postgres instance in myPostgres separate from the keycloakPostgres. To distinguish between the two, I use a nameOverride for the keycloak postgresql chart:

keycloak:
   postgresql:
      nameOverride: keycloak-postgres

That approach worked well in 18.1.1 ...if I named my release "r1" I'd end up with pods (and services) like

• r1-mine
• r1-postgres
• r1-keycloak
• r1-keycloak-postgres

Unfortunately, after upgrading, that now results in the keycloak init container failing repeatedly. Instead of r1-keycloak-postgres (<Release.name>-<nameOverride>) the init container is now trying to connect (via nc) to r1-keycloak-keycloak-postgres (note the extra "keycloak" in there).

I think its due to this particular change: https://github.com/codecentric/helm-charts/commit/d8a7733347a95a64101fb52484c184a8b1f0a235

Is there a way to customize the embedded keycloak postgresql deployment name to achieve something similar to what we were doing with 18.1.1 ?

[lmsurpre]

Actually, it looks like keycloak.postgresql.fullname is wrong even if I don't use a nameOverride. It results in service names like:

• r1-mine
• r1-mypostgres
• r1-mypostgres-headless
• r1-keycloak-http
• r1-keycloak-headless
• r1-postgresql
• r1-postgresql-headless

But the keycloak init container is running nc -z -w 2 r1-keycloak-postgresql 5432

I think anyone trying to use the codecentric keycloak chart as a subchart will hit this. I'll update the issue title accordingly.

[lmsurpre]

Any plans to look into this? If I sent a PR to address it (probably by using https://stackoverflow.com/a/69515809/161022 to construct the service name from the postgresql subchart--assuming that works), would that be considered?

[grieshaber]

Hi @lmsurpre - sorry for the late response. A PR would be highly appreciated!

[lmsurpre]

Unfortunately it was more complicated than I was hoping. For now, I just "fixed" the issue on our side by overriding the keycloak.postgresql.fullname helper from within our chart (restoring it to the behavior from before https://github.com/codecentric/helm-charts/commit/d8a7733347a95a64101fb52484c184a8b1f0a235).

[github-actions[bot]]

This issue has been marked as stale because it has been open for 30 days with no activity. It will be automatically closed in 10 days if no further activity occurs.

[JoelTrain]

This issue is affecting me too.

[jgagnon44]

I am having this issue currently. Switching back to version 18.1.1 seems to have resolved the problem.

[github-actions[bot]]

This issue has been marked as stale because it has been open for 30 days with no activity. It will be automatically closed in 10 days if no further activity occurs.

[jmnote]

workaround...

root@wsl:~# helm list -n keycloak
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
kc      keycloak        4               2024-01-07 07:07:56.218268445 +0000 UTC deployed        keycloak-18.4.4 17.0.1-legacy

root@wsl:~# kubectl -n keycloak get pod
NAME              READY   STATUS     RESTARTS   AGE
kc-keycloak-0     0/1     Init:0/1   0          7m40s
kc-postgresql-0   1/1     Running    0          8m41s

root@wsl:~# kubectl -n keycloak logs kc-keycloak-0 -c pgchecker | head -4
Waiting for PostgreSQL to become ready...
nc: bad address 'kc-keycloak-postgresql'
nc: bad address 'kc-keycloak-postgresql'
nc: bad address 'kc-keycloak-postgresql'
...

Soluton (workaground):

postgresql:
  fullnameOverride: kc-keycloak-postgresql

Result (Successful):

root@wsl:~# kubectl -n keycloak logs kc-keycloak-0 -c pgchecker
Waiting for PostgreSQL to become ready...
...........PostgreSQL OK ✓