fix: ignore internal configs in config hash calculation - #8868

Closes #8371

Signed-off-by: Marco Nenciarini <[email protected]>
Signed-off-by: Armando Ruocco <[email protected]>
Co-authored-by: Armando Ruocco <[email protected]>
(cherry picked from commit 076273e)

…es (#10342)

When upgrading from an operator version that includes cnpg.* parameters
in the PostgreSQL configuration hash to one that excludes them (change
introduced in #8868), pods running the old and new operator end up
computing different hashes for the same effective configuration. The
uniformity check in reconcilePods then blocks indefinitely, waiting for
all pods to report the same hash, but that can never happen because the
remaining pods still use the old algorithm. Neither the rolling update
nor the in-place instance manager upgrade can run, since both live
behind the blocked check.

The fix introduces `isConfigNonUniformityFromUpgrade()`, which groups
pods by their operator version and checks whether the hash split aligns
exactly with the version split. If every pod running the same operator
version agrees on its hash, but different versions disagree, the
non-uniformity is structural and will never self-resolve. In that case
we skip the wait and let `handleRollingUpdate` proceed.

The operator version key combines both the bootstrap controller image
(changes on rolling updates) and the executable hash (changes on
in-place upgrades), so the deadlock is detected regardless of the
upgrade strategy.

When the non-uniformity is from normal config propagation (pods on the
same operator version reporting different hashes), the function returns
false and the existing wait-for-uniformity behavior is preserved. This
keeps the fix scoped strictly to the operator upgrade deadlock scenario,
with no change in behavior during normal operations.

Closes: #10348

Assisted-by: Claude
Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>

…es (#10342)

When upgrading from an operator version that includes cnpg.* parameters
in the PostgreSQL configuration hash to one that excludes them (change
introduced in #8868), pods running the old and new operator end up
computing different hashes for the same effective configuration. The
uniformity check in reconcilePods then blocks indefinitely, waiting for
all pods to report the same hash, but that can never happen because the
remaining pods still use the old algorithm. Neither the rolling update
nor the in-place instance manager upgrade can run, since both live
behind the blocked check.

The fix introduces `isConfigNonUniformityFromUpgrade()`, which groups
pods by their operator version and checks whether the hash split aligns
exactly with the version split. If every pod running the same operator
version agrees on its hash, but different versions disagree, the
non-uniformity is structural and will never self-resolve. In that case
we skip the wait and let `handleRollingUpdate` proceed.

The operator version key combines both the bootstrap controller image
(changes on rolling updates) and the executable hash (changes on
in-place upgrades), so the deadlock is detected regardless of the
upgrade strategy.

When the non-uniformity is from normal config propagation (pods on the
same operator version reporting different hashes), the function returns
false and the existing wait-for-uniformity behavior is preserved. This
keeps the fix scoped strictly to the operator upgrade deadlock scenario,
with no change in behavior during normal operations.

Closes: #10348

Assisted-by: Claude
Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>
(cherry picked from commit 324709c)