Openshift - operator upgrade - OLM wants to upgrade 2.9.0 straight to 3.1.0

PostgreSQL Percona Operator for PostgreSQL
1

Hi,

I have Percona Operator for Postgresql certified version 2.9.0-cw installed on an Openshift cluster. According to documentation, we have to go through all minor versions, so to upgrade from 2.9.0 to 3.1.0, 3.0.0 must be installed first.

In openshift, the subscription was set to the stable-cw channel. I switched it to stable. Now, OLM offers to upgrade to 3.1.0, skipping 3.0.0. Is it safe to proceed? If not, how to force OLM to upgrade to 3.0.0. instead of 3.1.0?

Thank you!

2

Hey @eprevost ,

This is a limitation related to the certified OLM bundles and the OpenShift versions for which each operator version was certified.

In general, our recommendation is to upgrade OpenShift through each minor version and update the operator bundle accordingly at each step. This ensures that OLM follows the supported upgrade path and that the corresponding certified bundle is available for that OpenShift version.

For example, rather than keeping the same OpenShift version while moving directly across multiple operator versions, the recommended approach is to upgrade OpenShift minor by minor and update the operator bundle along the way.

Could you please confirm:

  • Which OpenShift version was running when PGO 2.9.0-cw was originally installed?

  • Which OpenShift version is the cluster running now?

This will help us understand which certified bundles should be available and determine the appropriate upgrade path from 2.9.0-cw to 3.1.0.

Thank you!

3

Operator version 2.8.2 was originally installed on openshift 4.19. Openshift has been upgraded to 4.20 since then and the operator was updated to 2.9.0 right after. Openshift is still on 4.20.

4

Hi @eprevost,

In the meantime, I have tested the API migration from 2.9.0 to 3.1.0, and this specific upgrade path works correctly when using the OpenShift bundles.

However, this should not be considered a generally supported approach for skipping intermediate versions. At this time, we only support upgrade paths that have been explicitly validated from one version to the next.

Each upgrade path needs to be tested individually to ensure that API and CR migrations are handled correctly and, more importantly, that the upgrade does not introduce service disruption, data availability issues, or unexpected behaviour in existing clusters.

We are currently working on improving the OpenShift bundle upgrade process so that upgrades can be performed safely from one supported operator version to the next. The necessary changes and validation are in progress, and we expect this upgrade flow to be available soon.

Therefore, while 2.9.0 → 3.1.0 has been validated in this specific scenario, the recommended approach for other version combinations remains to follow the documented upgrade path until the corresponding direct upgrade paths have been tested and officially supported.

Thank you!

5

That’s exactly why didn’t want to blindly click approve in Openshift!

Thank you for validating this specific upgrade scenario