fix: external PostgreSQL & Redis configurations

[nimish-ks]

Changes made:

• Deprecated Values.global.external.enabled in favor of .Values.database.external and or .Values.redis.external
• Updated configmap and migration hooks to depend only on database
• global.external.enabled no longer affects whether these Deployments/PVCs are created.

Addressed #31 issue.

---

Note

^{Cursor Bugbot is generating a summary for commit 1ce8fa4. Configure here.}

[cursor]

Bug: Migration Hook Timing Needs Redis Awareness

The migrations job runs as a pre-install hook when database.external is true, but it has an init container that waits for Redis. When Redis is internal (redis.external = false) and the database is external (database.external = true), the migrations job runs before the Redis deployment is created, causing the wait-for-redis init container to fail. The hook timing should depend on both database.external and redis.external being true.

 

[connorv001]

Does the job migration depend on both the database and Redis being available ?
If we go with this logic we are checking only the status of database isn't it? Like lets say a user is using RDS but want to run redis inside kubernetes cluster - in that case, this condition will pass but migration job since it's pre-install probably will cause issues due to how helm works.
I suggest we rather do :

    {{- if and .Values.database.external .Values.redis.external }}
    "helm.sh/hook": "pre-install,pre-upgrade"
    {{- else }}
    "helm.sh/hook": "post-install,post-upgrade"
    {{- end }}

[connorv001]

Additional suggestion from simulation.

• The migrations Job uses a pre-install hook when database.external = true

• Pre-install hooks execute before any regular resources are created

• The Job has a wait-for-redis init container that requires Redis to be available

• Internal Redis Deployment is a regular resource, not created until after hooks complete

• Init container waits indefinitely for Redis that doesn't exist yet

• Migration Job fails, blocking entire Helm installation

• Root cause: Hook timing logic only checks database.external, ignoring redis.external

[connorv001]

I actually do not understand why do we have this as a pre-install hook?
was there any reason for this design?

[connorv001]

The only remaining edge case I’m worried about is when:

1. database.external = true (e.g. RDS)
2. redis.external = false (Redis inside this chart)

With the current logic, the migrations Job runs as a pre-install hook based solely on database.external, but the Job still has the wait-for-redis init container.