Changing spilo image ignored when updating Postgres major version at the same time

• Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.8.1
• Where do you run it - cloud or metal? Kubernetes or OpenShift? Bare Metal K8s
• Are you running Postgres Operator in production? no
• Type of issue? question

I'm trying to understand how to properly execute a major postgres update using the operator CRD. Currently the issue I'm facing is when updating the spilo image in the operator-default-configuration from PG13 to PG14 and updating the postgres version in the postgres cluster manifest, the operator will perform a rolling update on the postgres cluster but will not update the image to PG14 until a reboot of the operator is triggered.

Operator configuration for PG13:

apiVersion: "acid.zalan.do/v1"
kind: OperatorConfiguration
metadata:
  name: postgresql-operator-default-configuration
configuration:
  docker_image: modifiedSpiloImageOnPG13:2.1-p5-13
...
major_version_upgrade:
    major_version_upgrade_mode: "full"
    minimal_major_version: "13"
    target_major_version: "14"

Changed to:
docker_image: modifiedSpiloImageOnPG14:2.1-p5-14

Postgres Cluster manifest:

  postgresql:
    version: "13"

To:

  postgresql:
    version: "14"

kubectl apply operator-config.yaml
kubectl apply postgres-cluster.yaml

After these modifications, the operator will trigger a rolling update that will only change the postgresql version. It will not change the spilo image. But if I force the operator to restart, it will then notice the new image in it's configuration and trigger another rolling update that will update the spilo image correctly.

Is there a way to trigger the image rolling update without having to restart the operator?

Start by reproducing the behavior with the OperatorConfiguration and Postgres cluster manifests described in the report: change the Spilo image and PostgreSQL version, then observe the rolling update without restarting the operator. Trace how configuration changes are picked up during reconciliation, and consider the behavior fixed when the new image is applied during the same update without an operator restart.