[charts/gateway] Add h2 option when deploy gateway

[xz-brcm]

Description of the change

Adds a new optional database.type field to the Gateway Helm chart values.yaml and production-values.yaml. When set to "h2", the chart injects SSG_DATABASE_TYPE=h2 into the Gateway container, enabling the H2 embedded database. This surfaces an existing capability in the Gateway container (entrypoint.sh) that was previously only configurable by passing the environment variable directly via additionalEnv.

Benefits

• Customers can switch to the H2 embedded database through a standard Helm values field, without needing additionalEnv workarounds.
• Zero impact on existing deployments — the field defaults to empty and no SSG_DATABASE_TYPE is injected, preserving current Derby/MySQL behaviour.
• Misconfigurations (e.g. setting type: h2 alongside a JDBC URL) produce clear error messages at container startup via existing entrypoint guards.

How to use

To enable H2, set the following in your values.yaml:

database:
  enabled: false
  create: false
  type: "h2"

To continue using Derby (default) or MySQL, no change is required. Omit type or leave it empty.

Drawbacks

• Helm-level validation for conflicting combinations (e.g. type: h2 with database.enabled: true) is not enforced at install time; misconfigurations are caught at container boot by the entrypoint.

Applicable issues

• fixes #

Additional information

The Gateway container entrypoint.sh already supported H2 via SSG_DATABASE_TYPE=h2. This chart change simply exposes that knob through the standard values interface. Both values.yaml and production-values.yaml have been updated to keep the two files in sync.

Checklist

• Chart version bumped in Chart.yaml according to semver.
• Variables are documented in the README.md
• Title of the PR starts with chart name (e.g. [charts/gateway])
• If the chart contains a values-production.yaml apart from values.yaml, ensure that you implement the changes in both files

[jchanbcbc]

Could add to the release notes about the support of h2

[jchanbcbc]

Issue 1 — Split-brain when database.type: "h2" and database.enabled: true are both set

File: charts/gateway/templates/configmap.yaml line 38
Severity: High

SSG_DATABASE_TYPE is injected with no awareness of database.enabled. In configmap.yaml, two independent blocks exist:

# Lines 29-37: MySQL JDBC URL — only when disklessConfig.enabled AND database.enabled
{{- if .Values.disklessConfig.enabled }}
  {{- if .Values.database.enabled }}
  SSG_DATABASE_JDBC_URL: jdbc:mysql://...

# Lines 38-40: Database type — only when database.type is non-empty, NO database.enabled check
{{- if .Values.database.type }}
  SSG_DATABASE_TYPE: {{ .Values.database.type | lower | quote }}

The default is database.enabled: true. A user who sets database.type: "h2" but forgets to also set database.enabled: false gets both keys emitted simultaneously:

SSG_DATABASE_JDBC_URL: jdbc:mysql://my-release-mysql:3306/ssg   # from the MySQL block
SSG_DATABASE_TYPE: "h2"                                          # from the new block

The Gateway container receives contradictory signals. Which wins depends on entrypoint.sh precedence logic that the Helm chart has no visibility into.

[jchanbcbc]

Issue 2 — No fail guard enforces the database.enabled: false prerequisite at install time

File: charts/gateway/values.yaml line 650 / charts/gateway/templates/configmap.yaml
Severity: High

The constraint lives only in a comment, not in the chart logic:

# Set to "h2" to use the H2 embedded database. Requires database.enabled: false.

Neither template has a validation block. Without this, helm install and helm upgrade succeed silently regardless of the conflicting combination. The error only surfaces at container boot — after the pod has been scheduled, pulled, and started — which is a much slower and harder feedback loop than a render-time failure.

The chart already uses required elsewhere (e.g. node-properties-secret.yaml line 31):

{{ required "Please set .Values.database.jdbcURL" .Values.database.jdbcURL }}

Same idiom applies here — just fail instead of required since this is a conditional constraint rather than a missing required value. The fix is the same fail block shown in Issue 1.

Without this, helm install and helm upgrade succeed silently regardless of the conflicting combination. The error only surfaces at container boot — after the pod has been scheduled, pulled, and started — which is a much slower and harder feedback loop than a render-time failure. The chart already uses required elsewhere (e.g. node-properties-secret.yaml line 31: {{ required "Please set .Values.database.jdbcURL" .Values.database.jdbcURL }}), so the pattern is established.

[emilytzhang]

Please update the README file as well

[jchanbcbc]

The Gateway has two mutually exclusive configuration modes:

• disklessConfig.enabled: true — reads config from environment variables mounted from the ConfigMap. The node-properties-secret.yaml Secret is not rendered at all.
• disklessConfig.enabled: false — reads config from node.properties in the Secret. ConfigMap DB env vars are intentionally suppressed.

Every DB-related env var respects this gate — except the new one:

Line 29:  {{- if .Values.disklessConfig.enabled }}    ← gate: only in diskless mode
Line 32:    SSG_DATABASE_JDBC_URL: jdbc:mysql://...
Line 37:  {{- end }}                                   ← gate closes

Line 38:  {{- if .Values.database.type }}              ← NO diskless gate
Line 39:    SSG_DATABASE_TYPE: "h2"                   ← always emitted
Line 40:  {{- end }}

When disklessConfig.enabled: false and database.type: "h2", the Secret renders correctly with node.db.type=h2 AND the ConfigMap also emits SSG_DATABASE_TYPE: "h2" — even though in this mode the Gateway is supposed to ignore ConfigMap env vars for DB config. Today both sources agree, so it is harmless. But the intent of disklessConfig.enabled: false is that node.properties is the single source of truth. If the Gateway's entrypoint.sh ever changes its precedence logic, a stale or different database.type in the ConfigMap could silently override node.properties with no indication to the operator that two sources are in play.

Fix: Move the new block inside the existing disklessConfig.enabled gate:

{{- if .Values.disklessConfig.enabled }}
  {{- if .Values.database.enabled }}
  SSG_DATABASE_JDBC_URL: ...
  {{- end }}
  {{- if .Values.database.type }}
  SSG_DATABASE_TYPE: {{ .Values.database.type | lower | quote }}
  {{- end }}
{{- end }}

[jchanbcbc]

My issues have been addressed.