Fix/migrate away from bitnamilegacy

[ervcz]

[Title: describe the change in one sentence]

[ describe the change in 1 - 3 paragraphs ]

How to use

[ describe what reviewers need to do in order to validate this PR ]

Testing done

[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[Copilot]

Pull request overview

Migrates Nebraska’s bundled PostgreSQL deployment from Bitnami to an in-chart StatefulSet using the official PostgreSQL image.

Changes:

• Adds PostgreSQL resources, persistence, authentication, probes, and migration validation.
• Removes Bitnami dependencies and repository configuration.
• Updates documentation, chart metadata, changelog, and CI workflows.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Summary
charts/nebraska/values.yaml	Defines bundled PostgreSQL configuration and defaults.
charts/nebraska/templates/postgresql.yaml	Adds PostgreSQL resources. Critical (3 votes): custom PGPORT does not change the server listen port.
charts/nebraska/templates/NOTES.txt	Adds migration guidance. Critical (1 vote): password guidance does not rotate an existing Secret. Moderate (4 votes): two commands contain pod-name syntax errors. Nit (4 votes): stranded comma should be a semicolon.
charts/nebraska/templates/deployment.yaml	Updates database connection and rollout behavior.
charts/nebraska/templates/_validate.tpl	Adds migration and configuration guards. Moderate (4 votes): child keys in known maps are not validated. Moderate (2 votes): the migration gate is not limited to the legacy layout transition.
charts/nebraska/templates/_helpers.tpl	Adds PostgreSQL helpers. Critical (1 vote): probe values can enable shell syntax or execution.
charts/nebraska/README.md	Documents migration and usage. Moderate (4 votes): documented kubectl exec and backup commands contain pod-name syntax errors. Nit (3 votes): persistent migration instructions are contradictory.
charts/nebraska/Chart.yaml	Bumps chart metadata and removes the dependency.
charts/nebraska/Chart.lock	Removes the obsolete Bitnami lock entry.
CHANGELOG.md	Documents the PostgreSQL migration.
.github/workflows/helm-chart-release.yml	Removes Bitnami repository setup.
.github/workflows/helm-chart-lint-test.yaml	Adds render-guard checks.
.github/ct.yaml	Removes Bitnami chart repository configuration.

Suppressed comments (19)

charts/nebraska/README.md:185

• Deleting a PVC whose PV was changed to Retain leaves the PV's spec.claimRef pointing at the deleted claim. The new volume claim will not bind to that Released PV automatically; with dynamic provisioning this can create a different empty volume, so the restore can run against the wrong disk or remain Pending. Clear the retained PV's claim reference (or document the rebinding steps) before the upgrade.

$ kubectl delete pvc data-my-nebraska-postgresql-0

charts/nebraska/README.md:209

• The comma is attached to the pod name, so kubectl exec looks for my-nebraska-postgresql-0, and the restore command fails. Use the -- separator after the pod name.

$ kubectl exec -i my-nebraska-postgresql-0, \

charts/nebraska/README.md:215

• The comma is attached to the pod name, so kubectl exec looks for my-nebraska-postgresql-0, and the ANALYZE command fails. Use the -- separator after the pod name.

$ kubectl exec -i my-nebraska-postgresql-0, \

charts/nebraska/README.md:219

• The comma is attached to the pod name, so kubectl exec looks for my-nebraska-postgresql-0, and the verification query fails. Use the -- separator after the pod name.

$ kubectl exec -i my-nebraska-postgresql-0, \

charts/nebraska/README.md:583

• The comma is attached to the pod name, so this documented restore command targets pod/nebraska-postgresql-0, and fails. Use the -- separator before psql.

$ kubectl exec -ti pod/nebraska-postgresql-0, psql < backup.sql

charts/nebraska/README.md:230

• Step 5 deliberately stores replicaCount=0 in the release, but this final upgrade never sets it back to 1. Unless my-values.yaml happens to contain the original replica count and Helm merges it as expected, Nebraska remains scaled to zero even though this is labelled “Scale Nebraska back up.” Set the desired replica count explicitly here.

$ helm upgrade my-nebraska nebraska/nebraska --version 3.0.0 \
    -f my-values.yaml \
    --set postgresql.primary.persistence.enabled=true \
    --set postgresql.acknowledgeDataDirMigration=true

charts/nebraska/README.md:196

• Helm does not reset values to chart defaults merely because -f is omitted; --reset-values is the explicit reset option, and prior release values can carry the old image/persistence settings into an upgrade. This warning therefore gives the wrong failure mode (and makes the --reuse-values warning misleading). Explain that a cleaned values file is required because stale Bitnami values are rejected, rather than claiming persistence will automatically become false.

#    PASS YOUR OWN VALUES FILE. `helm upgrade` resets values to chart defaults
#    unless you supply them again, and 3.0.0 defaults persistence to false, so
#    omitting -f here renders PostgreSQL with no PVC at all and you would restore
#    the dump into an emptyDir that disappears on the next restart.
#    Do NOT use --reuse-values: it would resurrect the 2.0.0 bitnamilegacy image.

charts/nebraska/README.md:36

• This table promises that external-database users need no action, but validateUnknownValues is deliberately called even when postgresql.enabled is false and will reject active removed values such as postgresql.metrics.enabled=true. An external install carrying those old settings therefore cannot upgrade without editing its values. Either skip the PostgreSQL compatibility check when the bundled database is disabled or document this required cleanup instead of saying no action is needed.

| set `postgresql.enabled: false` and use an external database | **No action needed.** Nothing in this change touches you. |

charts/nebraska/README.md:406

• This NetworkPolicy selects PostgreSQL pods by the hard-coded default name label, but the chart's selector changes this label when postgresql.nameOverride is set. In that supported configuration the policy selects no database pods, so the generated ingress rule does not allow Nebraska to connect. Template the label with the same nameOverride-aware value used by nebraska.postgresql.selectorLabels.

            app.kubernetes.io/name: postgresql

charts/nebraska/README.md:413

• The example also hard-codes Nebraska's default name label. A top-level nameOverride changes nebraska.selectorLabels, so this policy then denies the actual Nebraska pods and the bundled database becomes unreachable. Use the chart helper (or the same nameOverride-aware expression) here instead of nebraska.

                    app.kubernetes.io/name: nebraska

charts/nebraska/README.md:416

• The policy example permits only port 5432, while postgresql.service.port is configurable and is used by the chart for the Service and application connection. With a custom port, applying this recommended policy blocks all database traffic. Template the port from the same value as the chart.

              - port: 5432

charts/nebraska/templates/NOTES.txt:17

• The comma is attached to the rendered pod name, so the note's second verification command targets a nonexistent pod such as <release>-postgresql-0,. Use the -- separator before psql.

    kubectl exec -n {{ .Release.Namespace }} {{ include "nebraska.postgresql.fullname" . }}-0, \

charts/nebraska/templates/NOTES.txt:46

• The -}} trims the newline after this conditional, so the rendered NOTES text concatenates the warning's last sentence with Get the application URL... (for example, manage.Get). Preserve the newline by removing the right-trim marker.

{{ end -}}

charts/nebraska/templates/NOTES.txt:35

• This warning only tests the configured value. If an operator resets values or supplies a fresh values file while the preserved Secret still contains changeIt, lookup keeps that password but this warning is omitted. Check the live Secret (or otherwise track the effective credential), not only .Values.

{{- if and .Values.postgresql.enabled (eq (.Values.postgresql.auth.postgresPassword | toString) "changeIt") (not .Values.postgresql.auth.existingSecret) }}

charts/nebraska/templates/_validate.tpl:98

• Non-boolean, non-string, non-slice, non-map values fall through this helper and produce no output. Consequently every unknown numeric value is classified as inert, so values such as postgresql.auth.removedSetting=1 or global.someSetting=1 are silently ignored instead of being rejected by the deny-unknown guard.

{{- else if kindIs "map" $v -}}

charts/nebraska/templates/_validate.tpl:95

• isInertValue treats every true boolean as non-inert, so default upstream settings such as auth.enablePostgresUser: true (and enabled default feature blocks such as shmVolume) are reported even though the README promises that a wholesale Bitnami values file left at defaults is accepted. Compare removed settings with their actual upstream defaults or explicitly classify these preserved defaults as inert.

{{- else if kindIs "bool" $v -}}
  {{- if not $v -}}inert{{- end -}}
{{- else if kindIs "string" $v -}}
  {{- if eq $v "" -}}inert
  {{- else if and (eq $k "architecture") (eq $v "standalone") -}}inert{{- end -}}

charts/nebraska/templates/_validate.tpl:263

• This special case reports every non-empty old probe map, including the upstream defaults (enabled: true plus the default timings). Therefore a wholesale Bitnami values.yaml, which this PR says should be accepted when values remain at defaults, is rejected for primary.livenessProbe and primary.readinessProbe even when the user never customized them. Distinguish an explicit non-default/disabled probe from the old default map instead of testing only whether the map is non-empty.

{{- if $v -}}
{{- $found = append $found (printf "postgresql.primary.%s: probes are fixed by this chart. postgresql.startupProbe tunes the first-start budget." $k) -}}
{{- end -}}

charts/nebraska/templates/deployment.yaml:6

• The documented 5432 fallback is only selected from postgresql.enabled, not from whether config.database.host is an external host. If a user sets an external host but leaves the bundled database enabled (the values comment explicitly describes this as an external-host case), an empty config.database.port makes Nebraska connect to the external server on postgresql.service.port instead of 5432. Include the host selection in this condition or require an explicit port for that configuration.

{{- $port := .Values.config.database.port | default (ternary .Values.postgresql.service.port 5432 .Values.postgresql.enabled) | toString }}

charts/nebraska/templates/postgresql.yaml:28

• This validation is unconditional, so an external-database release with postgresql.enabled: false still fails if it carries a non-inert removed Bitnami value such as postgresql.metrics.enabled=true. That value rendered nothing when the dependency was disabled, and the README promises external-database users need no action. Either skip this removed-value check when the bundled database is disabled or update the documented upgrade contract.

{{- include "nebraska.postgresql.validateUnknownValues" . -}}

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 3 comments.

Suppressed comments (24)

charts/nebraska/README.md:168

• This migration command is not executable: the pod argument ends in a comma and there is no -- separator, so kubectl treats my-nebraska-postgresql-0, as the pod name. Replace the comma with --; the restore, ANALYZE, and verification commands below have the same typo.

$ kubectl exec my-nebraska-postgresql-0,     env PGPASSWORD="$PGPW" pg_dump -U postgres -d nebraska > nebraska.sql

charts/nebraska/README.md:209

• This restore command has the same invalid pod, syntax as the dump command: kubectl will not find my-nebraska-postgresql-0,. Use the -- command separator here (and on the following ANALYZE and verification commands).

$ kubectl exec -i my-nebraska-postgresql-0, \

charts/nebraska/README.md:549

• The existing PostgreSQL backup example was changed to an invalid pod/nebraska-postgresql-0, target. kubectl treats the comma as part of the resource name, so this backup command fails; retain the -- separator from the previous form.

$ kubectl exec -ti pod/nebraska-postgresql-0, pg_dumpall > backup.sql

charts/nebraska/README.md:583

• The restore example has the same accidental comma in the pod target and will fail before psql runs. Keep the -- separator here as well.

$ kubectl exec -ti pod/nebraska-postgresql-0, psql < backup.sql

charts/nebraska/README.md:215

• This ANALYZE command still passes the pod name with a trailing comma, so the documented post-restore verification fails before PostgreSQL is invoked. Replace the comma with --.

$ kubectl exec -i my-nebraska-postgresql-0, \

charts/nebraska/README.md:219

• This verification command also uses my-nebraska-postgresql-0, as the pod name, so the migration procedure cannot reach the database. Use -- before the command.

$ kubectl exec -i my-nebraska-postgresql-0, \

charts/nebraska/README.md:38

• This upgrade summary says in-place reuse is “not yet a supported path,” but the same README immediately provides a tested in-place procedure and the changelog describes same-major reuse as an available option. That contradiction makes the supported migration path unclear for operators; align this statement with the actual support policy and label the procedure consistently.

| run with `postgresql.primary.persistence.enabled: true` | **Action required, dump and restore.** See below. Reusing the volume in place is being investigated but is not yet a supported path. |

charts/nebraska/README.md:175

• Retaining the PV is not enough to make the new StatefulSet use it: deleting the old PVC leaves a retained PV in Released state with its old claimRef, so the newly created data-... claim normally binds a fresh volume (or stays Pending) instead of this PV. Add explicit claim release/rebinding steps and verify the new PVC before restoring, or avoid deleting and recreating the claim.

$ PV=$(kubectl get pvc data-my-nebraska-postgresql-0 -o jsonpath='{.spec.volumeName}')
$ kubectl patch pv "$PV" -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

charts/nebraska/README.md:406

• This NetworkPolicy example hardcodes app.kubernetes.io/name: postgresql, but the chart's PostgreSQL selector honors postgresql.nameOverride. With nameOverride: pg, the policy selects no database pods and does not protect/allow the intended workload. Use the same nameOverride expression in the example or explicitly tell users to substitute it.

            app.kubernetes.io/name: postgresql

charts/nebraska/README.md:416

• The example hardcodes ingress port 5432 even though postgresql.service.port is configurable and the chart's Service/probe contract follows that value. For a custom port, applying this policy blocks the database traffic it is meant to allow. Render or substitute .Values.postgresql.service.port in the example.

              - port: 5432

charts/nebraska/README.md:413

• The application selector is also hardcoded to nebraska, while nebraska.selectorLabels uses the top-level nameOverride. With a custom application name, this policy permits no Nebraska pods to connect. Use the chart helper in the templated extraObjects example.

                    app.kubernetes.io/name: nebraska

charts/nebraska/templates/NOTES.txt:35

• This warning checks only .Values.postgresql.auth.postgresPassword, but the Secret template deliberately preserves the live postgres-password via lookup. On an upgrade or reinstall using a fresh values file, the value can be empty while the existing Secret still contains the 2.0.0 changeIt password, so this warning is skipped and the known credential remains active. Inspect the preserved Secret here (or require rotation) so the migration does not falsely report the fixed default as gone.

{{- if and .Values.postgresql.enabled (eq (.Values.postgresql.auth.postgresPassword | toString) "changeIt") (not .Values.postgresql.auth.existingSecret) }}

charts/nebraska/templates/NOTES.txt:12

• The NOTES command passes a pod name ending in a comma and omits kubectl's -- separator, so users copying the upgrade check will get a pod-not-found error. Replace the comma with --; the second check on line 17 has the same defect.

    kubectl exec -n {{ .Release.Namespace }} {{ include "nebraska.postgresql.fullname" . }}-0, \

charts/nebraska/templates/NOTES.txt:17

• This second NOTES command also uses {{ include "nebraska.postgresql.fullname" . }}-0, as the pod name, so the advertised row-count check cannot run. Use the -- separator before psql.

    kubectl exec -n {{ .Release.Namespace }} {{ include "nebraska.postgresql.fullname" . }}-0, \

charts/nebraska/templates/NOTES.txt:33

• The sentence is malformed by the leading comma in , run the two commands above, which makes the rendered upgrade warning read incorrectly. Replace it with a semicolon and keep run as the next clause.

 , run the two commands above.

charts/nebraska/templates/_validate.tpl:123

• image and service are put in $known, but unlike auth, serviceAccount, and primary they are never scanned for unsupported nested keys. A carried-over value such as postgresql.service.type: NodePort or postgresql.image.debug: true therefore passes validation and is silently discarded; the rendered Service is hard-coded to ClusterIP. Add nested allowlists/checks for these maps so non-inert settings fail rather than being lost.

  "auth" "image" "service" "dataMountPath" "dataSubdir" "primary"
  "serviceAccount" "podSecurityContext" "containerSecurityContext"

charts/nebraska/templates/_validate.tpl:49

• This condition fires for every helm upgrade with persistence enabled, not just the 2.0.0 → 3.0.0 migration described by the value and error text. After a successful 3.0.0 install, a later patch upgrade still fails unless the operator remembers to keep acknowledgeDataDirMigration=true forever (a one-time --set is not enough). Scope the check to the actual pre-3.0 release or persist a migration marker/document that the acknowledgement must remain set.

{{- if and .Release.IsUpgrade $pg.enabled ((($pg.primary | default dict).persistence | default dict).enabled) -}}
{{- if ne ($pg.acknowledgeDataDirMigration | toString) "true" -}}
{{- fail "\n\nSTOP. This upgrade would silently discard your database.\n\nChart 3.0.0 replaced the Bitnami postgresql subchart with the official postgres\nimage, which stores data at a different path inside the same volume:\n\n  chart 2.0.0 (Bitnami):  PVC mounted at /bitnami/postgresql       PGDATA=/bitnami/postgresql/data\n  chart 3.0.0 (official): PVC mounted at /var/lib/postgresql/data  PGDATA=/var/lib/postgresql/data/pgdata\n\nNothing in Kubernetes rejects this change, so `helm upgrade` would SUCCEED and\nPostgreSQL would initialise a brand-new empty database alongside your existing\none. Nebraska would come up looking healthy with no applications, groups or\nrollouts, and no error would be reported.\n\nYou have persistence enabled, so you must choose:\n\n  1. Migrate the data (dump/restore). Follow \"Upgrading to 3.0.0\" in the chart\n     README, then re-run with:\n         --set postgresql.acknowledgeDataDirMigration=true\n\n  2. Deliberately start from an empty database (fine for dev/test). Same flag:\n         --set postgresql.acknowledgeDataDirMigration=true\n\n  3. Stay on chart 2.0.0 for now.\n\nIf you already ran this upgrade by accident: your old cluster is still present\non the volume, untouched, in the `data/` directory. Run `helm rollback` NOW,\nbefore deleting any PVC, and it will come back.\n" -}}

charts/nebraska/templates/_validate.tpl:47

• This gate is conditioned only on .Release.IsUpgrade, so uninstall/reinstall is treated as a fresh install. A persistent 2.0.0 StatefulSet leaves its data-<release>-postgresql-0 PVC behind; reinstalling 3.0.0 with the same release name skips the gate, initializes pgdata next to the old cluster, and Nebraska comes up empty. Detect an existing PVC/legacy marker on install too, or require acknowledgement whenever an existing persistent volume is reused.

{{- if and .Release.IsUpgrade $pg.enabled ((($pg.primary | default dict).persistence | default dict).enabled) -}}

charts/nebraska/templates/_validate.tpl:264

• isInertValue treats every map with enabled: false as inert. Consequently, carried-over postgresql.primary.podSecurityContext.enabled: false or containerSecurityContext.enabled: false passes validation even though this chart always emits replacement security contexts with different uid/gid and filesystem settings; those values are silently ignored during migration. Special-case these security-context blocks like the probe blocks and report them.

{{- else if not (include "nebraska.postgresql.isInertValue" (dict "key" $k "value" $v)) -}}

charts/nebraska/templates/deployment.yaml:6

• The fallback tests only postgresql.enabled, not whether config.database.host was overridden. With an external host and a customized postgresql.service.port (for example 15432), Nebraska is pointed at the external database on 15432 instead of the documented external default 5432. Base the ternary on bundled mode (enabled and empty host), or require an explicit external port.

{{- $port := .Values.config.database.port | default (ternary .Values.postgresql.service.port 5432 .Values.postgresql.enabled) | toString }}

charts/nebraska/templates/postgresql.yaml:239

• PGPORT is a libpq client environment variable; it does not configure the PostgreSQL server's listening port. If postgresql.service.port is changed from 5432, the Service and container port move, but the official image still starts postgres on its default 5432, so Nebraska cannot connect. Pass the port to the server command (for example with -p/-c port=..., while preserving any user override) instead of relying on PGPORT.

            - name: PGPORT
              value: {{ $pgPort | quote }}

charts/nebraska/templates/postgresql.yaml:380

• volumeClaimTemplates is immutable on an existing StatefulSet. Therefore a 2.0.0 release created with persistence disabled cannot be upgraded in place after setting postgresql.primary.persistence.enabled=true: this newly rendered block will make the API reject the StatefulSet update. The migration docs only cover already-persistent installs; either provide a supported recreate/migration path or fail with an explicit, actionable message for this transition.

  {{- if $persistence.enabled }}
  volumeClaimTemplates:

charts/nebraska/templates/postgresql.yaml:395

• Unlike the existing templates/pvc.yaml, this PVC template only emits postgresql.primary.persistence.labels/annotations. The chart documents top-level extraLabels and extraAnnotations as applying to all objects, and the existing PVC template applies them, so backup/retention metadata set there is silently lost for the bundled database. Merge both sources into this PVC metadata without emitting duplicate YAML keys.

        {{- with $persistence.labels }}
        labels:
          {{- toYaml . | nindent 10 }}
        {{- end }}
        {{- with $persistence.annotations }}
        annotations:
          {{- toYaml . | nindent 10 }}

charts/nebraska/README.md:36

• This row says external-database users need no action, but postgresql.yaml invokes validateUnknownValues unconditionally. A values file retaining a non-inert Bitnami key (for example postgresql.metrics.enabled=true) still fails every 3.0.0 render even with postgresql.enabled=false. Clarify that no database migration is needed but stale values still must be removed, or change the guard behavior.

| set `postgresql.enabled: false` and use an external database | **No action needed.** Nothing in this change touches you. |