fix: zero PodUpdatePolicy and PodUpgradePolicy in cmpdHash to prevent immutable-hash mismatch

[Alegrowin]

Summary

When addon charts don't explicitly set podUpdatePolicy in their ComponentDefinition templates, the operator defaults it to PreferInPlace after creation. This changes the apps.kubeblocks.io/immutable-hash annotation, causing reconciliation to fail with "immutable fields can't be updated".

PodManagementPolicy is already treated as mutable (zeroed before hashing in cmpdHash()). This PR applies the same treatment to PodUpdatePolicy and PodUpgradePolicy.

Root Cause

The podUpdatePolicy field was added to ComponentDefinitionSpec with default PreferInPlace, but cmpdHash() was not updated to exclude it from the immutable hash. Any ComponentDefinition created before the field existed (or by an addon chart that doesn't set it) gets a different hash after the operator defaults the field — triggering immutability violations.

Changes

• controllers/apps/componentdefinition_controller.go: zero PodUpdatePolicy and PodUpgradePolicy in cmpdHash() alongside PodManagementPolicy

Companion PR

• apecloud/kubeblocks-addons: adds podUpdatePolicy: PreferInPlace to all 122 cmpd templates (prevents the defaulting from happening)

[CLAassistant]

All committers have signed the CLA.

[apecloud-bot]

Auto Cherry-pick Instructions

Usage:
  - /nopick: Not auto cherry-pick when PR merged.
  - /pick: release-x.x [release-x.x]: Auto cherry-pick to the specified branch when PR merged.

Example:
  - /nopick
  - /pick release-1.1

[leon-ape]

I checked the history, and podUpdatePolicy / podUpgradePolicy were introduced into the v1 ComponentDefinition API in the 1.0 release line starting from v1.0.2, not v1.0.0 or v1.0.1. So the real compatibility case here is for v1 ComponentDefinition objects created on v1.0.0 / v1.0.1, whose stored immutable hash was generated before these fields existed. After upgrading to a version where these fields are present, the newly computed hash may differ even if the user did not change the object.

Given that, the controller-side fix in this PR makes sense. But this is independent of whether addon manifests explicitly set podUpdatePolicy: PreferInPlace. Once cmpdHash() excludes these fields, the compatibility issue is addressed. Explicitly adding the default value in addon charts does not contribute to fixing this problem, so I do not think the companion addon PR is necessary.

[leon-ape]

/pick release-1.0

[leon-ape]

/pick release-1.1

[leon-ape]

/approve

[leon-ape]

Thanks for the contribution. I will merge this PR and cherry-pick it to release-1.0 and release-1.1.

[apecloud-bot]

/cherry-pick release-1.0

[apecloud-bot]

/cherry-pick release-1.1

[apecloud-bot]

🤖 says: cherry pick action finished successfully 🎉!
See: https://github.com/apecloud/kubeblocks/actions/runs/23328533335

[apecloud-bot]

🤖 says: cherry pick action finished successfully 🎉!
See: https://github.com/apecloud/kubeblocks/actions/runs/23328533392