[bitnami/postgresql] Global postgres fullname override, needed when the fullname needs to be shared across subcharts.

[KorenP1]

Description of the change

Added value global.postgresql.fullnameOverride.

Benefits

Global PostgreSQL fullname override, needed when the fullname needs to be shared across subcharts like the other global PostgreSQL values.

Possible drawbacks

None

Applicable issues

None

Additional information

The function changed to a single ternary operation for compact and read reasons.

Checklist

• Chart version bumped in Chart.yaml according to semver. This is not necessary when the changes only affect README.md files.
• Variables are documented in the values.yaml and added to the README.md using readme-generator-for-helm
• Title of the pull request follows this pattern [bitnami/<name_of_the_chart>] Descriptive title
• All commits signed off and in agreement of Developer Certificate of Origin (DCO)

[KorenP1]

@gongomgra @juan131

[juan131]

Hi @KorenP1

This isn't required, we solve it in other charts by creating a specific helper to get the PostgreSQL fullname. For instance, check the helper below:

• https://github.com/bitnami/charts/blob/main/bitnami/airflow/templates/_helpers.tpl#L71-L77

[KorenP1]

Hi @juan131
Thanks for reviewing.
The case you mentioned is when the postgresql chart is a subchart of the chart that needs the fully qualified postgresql name.
In other cases when the postgresql chart is a standalone rather than if the other tool chart is connecting to it or not, the fully qualified postgresql name needs to be passed somehow or to be static. global fullnameOverride is the best solution i found.
Hopefully the next childish demonstration i made in paint app will explain it :) Not specificly to airflow and pg. can be any chart with pg.

[gongomgra]

Hi @KorenP1

I understand in that case you can configure Airflow (and other apps in out catalog) using the .externalDatabase settings, no? See Airflow, and Redmine examples.

You may need to use the fully qualified domain name of the PostgreSQL service for the .externalDatabase.host parameter:

my-svc.my-namespace.svc.cluster-domain.example

In case this is not the solution for you, would you mind providing us with more details?

[KorenP1]

Hi @gongomgra
That sometimes might be the case but in some cases the postgresql and the other chart (lets say airflow for this example) are independent of each other.
Ill explain my case.
I have a chart that deploys some of my own services and also needs to connect to both airflow and postgres, those airflow and postgres can be as part of the helm and can be external. They also can be seperated as one of them will be part of the helm and the other will be external so i cant use the postgresql as a subchart of the airflow chart because sometimes i might want to deploy postgres and not deploy the airflow chart.
When i want to deploy both of the airflow and postgresql charts, the airflow needs to know where the postgres located, which is <fullnameOverride>:5432 in my case.

Again, i cant use the postgresql as subchart of airflow because in some cases i will want to deploy only postgres.
I am using externalDatabase.host but for that i need to know the host of the postgres, which again is <postgres_service_name>:, for that to be dynamic the postgres name have to be exported as global, as already implemented in the service port number.

[KorenP1]

@juan131 @gongomgra
If there are any questions I can email you guys privately

[juan131]

Thanks for explaining your use case @KorenP1

The issue here is that one of the sub-charts your chart deploys (Airflow in the example) uses another sub-chart as db backend (PostgreSQL in the example) hence you need to know the svc name where to connect (which is affected by the fullname override).

Please correct me if I'm wrong but this can be achieved without using global parameters:

(...)
postgresql:
  fullnameOverride: pg
airflow:
  postgresql:
    enabled: false
  externalDatabase:
    host: pg

[KorenP1]

@juan131
Thanks.
yes this will absolutely work. The thing is i want to do it dynamically with the following values example

postgresql:
  fullnameOverride: pg
airflow:
  postgresql:
    enabled: false
  externalDatabase:
    host: '{{ .Values.global.postgresql.fullnameOverride }}'

[juan131]

All right! IMO your is quiet a specific use case, but, given the change doesn't introduce any technical concern I'm okay with accepting it. Thanks for the contribution.