Skip to content

Conversation

@zdrapela
Copy link
Member

@zdrapela zdrapela commented Jan 16, 2026

Description of the change

Upgrade the integrated PostgreSQL from version 15 to 16.

Users who are updating from the previous version of the chart need to follow the upgrade process as outlined in the logs of the PostgreSQL pod. That means helm upgrade, configuring upstream.prostgresql.extraEnvVars key to include POSTGRESQL_UPGRADE="copy". The complete configuration of the key would look like this (it needs to contain the config of POSTGRESQL_ADMIN_PASSWORD to avoid having extraEnvVars overridden without it):

upstream:
  postgresql:
    primary:
      extraEnvVars:
        - name: POSTGRESQL_UPGRADE
          value: "copy"
        - name: POSTGRESQL_ADMIN_PASSWORD
          valueFrom:
            secretKeyRef:
              key: postgres-password
              name: '{{- include "postgresql.v1.secretName" . }}'

After that, perform helm upgrade again, removing the POSTGRESQL_UPGRADE variable for continued regular use.

After that, a refresh of PostgreSQL collation versions is required (outlined in the PostgreSQL pod logs). This can be done, for example, like this: https://github.com/redhat-developer/rhdh/pull/3949/files#diff-5700e984b56368043ef9a0c1ab37e906444544c1fb8e47beb8189366fa0602c9R1054-R1110

The complete upgrade was tested in redhat-developer/rhdh#3949

Which issue(s) does this PR fix or relate to

How to test changes / Special notes to the reviewer

Checklist

  • For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
  • For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Use pre-commit run -a to apply changes. The pre-commit Workflow will do this automatically for you if needed.
  • JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
  • Tests pass using the Chart Testing tool and the ct lint command.
  • If you updated the orchestrator-infra chart, make sure the versions of the Knative CRDs are aligned with the versions of the CRDs installed by the OpenShift Serverless operators declared in the values.yaml file. See Installing Knative Eventing and Knative Serving CRDs for more details.

@sonarqubecloud
Copy link

@rhdh-qodo-merge
Copy link

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶

RHIDP-10940 - Partially compliant

Compliant requirements:

  • Helm Chart values updated to use a PostgreSQL 16 container image.

Non-compliant requirements:

  • Existing deployments continue to work (backward compatibility).

Requires further human verification:

  • Update the RHDH Helm Chart configuration/values to deploy PostgreSQL 16 for the integrated database.
  • New Helm deployments create a PostgreSQL 16 database by default.
  • Configuration changes documented in the PR.
⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🔒 Security concerns

Supply chain / non-deterministic image versioning:
Using tag: latest for the database image can unintentionally pull newer images over time, which increases the risk of deploying unreviewed image changes (including potential vulnerabilities or breaking changes). Consider pinning a specific version tag or digest.

⚡ Recommended focus areas for review

Image Choice

The ticket context calls out using the latest Red Hat supported PostgreSQL image/version, but the chart is updated to quay.io/fedora/postgresql-16. Please verify this is the intended, supported image source for RHDH (and aligns with the stated “Red Hat supported PostgreSQL 16 container image availability” dependency) rather than a community Fedora image.

image:
  registry: quay.io
  repository: fedora/postgresql-16
  tag: latest
Pinning

PostgreSQL is configured with tag: latest, which can introduce non-deterministic upgrades and break reproducibility/backward compatibility expectations. Consider pinning to a specific PostgreSQL 16 image tag (or digest) and documenting the upgrade path accordingly.

image:
  registry: quay.io
  repository: fedora/postgresql-16
  tag: latest
📚 Focus areas based on broader codebase context

Version Skew

The chart now defaults to quay.io/fedora/postgresql-16:latest, but other existing deployment manifests in the wider ecosystem still reference quay.io/fedora/postgresql-15:latest. Validate that all supported installation paths (Helm chart vs. any operator-provisioned DB or test manifests) are updated/compatible, otherwise users may end up with mismatched PostgreSQL versions depending on how they deploy. (Ref 2, Ref 4)

image:
  registry: quay.io
  repository: fedora/postgresql-16
  tag: latest

Reference reasoning: The reference YAML manifests consistently pin the PostgreSQL container image to major version 15, indicating an established baseline across deployment/test configurations. Changing only the chart default to major version 16 risks diverging from those established manifests unless the related configs are updated or compatibility is explicitly ensured.

📄 References
  1. redhat-developer/rhdh-chart/charts/backstage/values.yaml [283-310]
  2. redhat-developer/rhdh-operator/config/profile/rhdh/default-config/db-statefulset.yaml [28-48]
  3. redhat-developer/rhdh-operator/config/profile/backstage.io/default-config/db-statefulset.yaml [28-48]
  4. redhat-developer/rhdh-operator/pkg/model/testdata/default-config/db-statefulset.yaml [18-48]
  5. redhat-developer/rhdh-operator/pkg/model/testdata/rhdh-db-statefulset.yaml [18-47]
  6. redhat-developer/rhdh-operator/pkg/model/testdata/janus-db-statefulset.yaml [18-47]
  7. redhat-developer/rhdh-operator/pkg/model/testdata/ips-db-statefulset.yaml [1-24]
  8. redhat-developer/rhdh-operator/config/profile/rhdh/default-config/db-statefulset.yaml [60-90]

@rhdh-qodo-merge rhdh-qodo-merge bot added the enhancement New feature or request label Jan 16, 2026
@rhdh-qodo-merge
Copy link

rhdh-qodo-merge bot commented Jan 16, 2026

PR Type

(Describe updated until commit 1cb2815)

Enhancement


Description

  • Upgrade PostgreSQL dependency from v15 to v16

  • Update chart version to 5.1.0 following semantic versioning

  • Update documentation and installation examples


File Walkthrough

Relevant files
Configuration changes
Chart.yaml
Increment chart version for release                                           

charts/backstage/Chart.yaml

  • Bumped chart version from 5.0.0 to 5.1.0
+1/-1     
Documentation
README.md
Update documentation with new version                                       

charts/backstage/README.md

  • Updated version badge from 5.0.0 to 5.1.0
  • Updated helm install command example to use v5.1.0
+2/-2     
Dependencies
values.yaml
Upgrade PostgreSQL image to v16                                                   

charts/backstage/values.yaml

  • Changed PostgreSQL image repository from fedora/postgresql-15 to
    fedora/postgresql-16
  • Maintains latest tag for automatic updates
+1/-1     

@rhdh-qodo-merge
Copy link

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
Possible issue
Pin database image to a specific version

Pin the PostgreSQL image to a specific version tag, such as "16", instead of
using latest. This will ensure deterministic and reliable deployments.

charts/backstage/values.yaml [275-278]

 image:
   registry: quay.io
   repository: fedora/postgresql-16
-  tag: latest
+  tag: "16"
  • Apply / Chat
Suggestion importance[1-10]: 8

__

Why: The suggestion correctly identifies that using the latest tag for the PostgreSQL image can cause unpredictable deployments and recommends pinning to a specific version, which is a critical best practice for stability and reproducibility.

Medium
  • More

@zdrapela
Copy link
Member Author

I'm not entirely sure how much we want to describe the upgrade process in the documentation and in the release notes. My impression is that it's clear from the pod logs of the PostgreSQL pod. Maybe just to mention that an upgrade of the PostgreSQL database is needed?

@zdrapela
Copy link
Member Author

The upgrade check failed on upgrade from 5.0.0 to 5.1.0, as an upgrade procedure needs to be executed (see the PR description).

# Versions are expected to follow Semantic Versioning (https://semver.org/)
# Note that when this chart is published to https://github.com/openshift-helm-charts/charts
# it will follow the RHDH versioning 1.y.z
version: 5.0.0
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or should it be bumped rather to 6.0.0?

@zdrapela zdrapela marked this pull request as ready for review January 16, 2026 13:56
@openshift-ci openshift-ci bot requested review from gazarenkov and rm3l January 16, 2026 13:56
@rhdh-qodo-merge
Copy link

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶

RHIDP-10940 - Partially compliant

Compliant requirements:

  • Update Helm Chart values to use a PostgreSQL 16 container image for the integrated database
  • Ensure new Helm deployments create PostgreSQL 16 database by default
  • Document configuration changes in the PR

Non-compliant requirements:

  • Ensure existing deployments continue to work (backward compatibility)

Requires further human verification:

  • Ensure existing deployments continue to work (backward compatibility)
⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🔒 Security concerns

Supply chain / unpinned image:
tag: latest for the PostgreSQL image can pull unexpected newer builds over time, reducing reproducibility and increasing the risk of inadvertently consuming a compromised or incompatible image version. Pin to a specific version tag (and ideally an image digest) to mitigate this.

⚡ Recommended focus areas for review

Backward Compatibility

The integrated PostgreSQL image was switched from 15 to 16, but the diff does not include any chart-level migration/upgrade automation or guardrails (e.g., notes, hooks, conditional logic). Existing installs may require manual steps and could fail or have data/collation upgrade requirements; validate that upgrade paths are handled or clearly surfaced to users via chart docs/templates.

    port: http-metrics
postgresql:
  enabled: true
  postgresqlDataDir: /var/lib/pgsql/data/userdata
  serviceBindings:
    enabled: true
  image:
    registry: quay.io
    repository: fedora/postgresql-16
    tag: latest
  auth:
    secretKeys:
      adminPasswordKey: postgres-password
Image Pinning

The PostgreSQL image uses tag: latest, which makes deployments non-reproducible and can cause unexpected upgrades. Consider pinning to an explicit Postgres 16 image tag (and ideally digest) aligned with the supported Red Hat image policy for this chart.

image:
  registry: quay.io
  repository: fedora/postgresql-16
  tag: latest
auth:
📄 References
  1. redhat-developer/rhdh-chart/charts/backstage/values.yaml [283-310]
  2. redhat-developer/rhdh-operator/pkg/model/testdata/default-config/db-statefulset.yaml [18-48]
  3. redhat-developer/rhdh-operator/pkg/model/testdata/rhdh-db-statefulset.yaml [18-47]
  4. redhat-developer/rhdh-operator/pkg/model/testdata/janus-db-statefulset.yaml [18-47]
  5. redhat-developer/rhdh-operator/config/profile/rhdh/default-config/db-statefulset.yaml [28-48]
  6. redhat-developer/rhdh-operator/config/profile/backstage.io/default-config/db-statefulset.yaml [28-48]
  7. redhat-developer/rhdh-operator/pkg/model/testdata/ips-db-statefulset.yaml [1-24]
  8. redhat-developer/rhdh-operator/pkg/model/testdata/default-config/db-statefulset.yaml [53-78]

@rhdh-qodo-merge
Copy link

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
General
Pin image to specific version

Pin the Postgres image to a specific version (e.g., 16.5.1) instead of using
latest for reproducible and predictable deployments.

charts/backstage/values.yaml [278]

-tag: latest
+tag: "16.5.1"
  • Apply / Chat
Suggestion importance[1-10]: 7

__

Why: This is a valuable suggestion as using the latest tag is a bad practice that can lead to unpredictable deployments and potential breaking changes. Pinning to a specific version is crucial for stability.

Medium
Show image tag pinning in example

Update the helm install example in the README to show how to pin the PostgreSQL
image version using --set postgresql.image.tag=.

charts/backstage/README.md [33]

-helm install my-backstage redhat-developer/backstage --version 5.1.0
+helm install my-backstage redhat-developer/backstage --version 5.1.0 \
+  --set postgresql.image.tag=16.5.1
  • Apply / Chat
Suggestion importance[1-10]: 6

__

Why: This suggestion improves the user-facing documentation by demonstrating a best practice (pinning the image version) in the installation example, which helps users adopt a more stable configuration.

Low
Add image pull policy

Add an explicit imagePullPolicy: IfNotPresent to the PostgreSQL image
configuration to make the image pulling behavior explicit and stable.

charts/backstage/values.yaml [275-277]

 image:
   registry: quay.io
   repository: fedora/postgresql-16
+  pullPolicy: IfNotPresent
  • Apply / Chat
Suggestion importance[1-10]: 4

__

Why: This is a good practice for explicitness, but its impact is minor. If the image tag is changed from latest (as suggested elsewhere), the default pullPolicy becomes IfNotPresent anyway, making this change less critical.

Low
  • More

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant