chore: keep KB-managed tools image updates in-place - #10484
Conversation
|
Auto Cherry-pick Instructions CLA Recheck Instructions |
3226dcf to
d34bf20
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #10484 +/- ##
==========================================
+ Coverage 63.40% 63.54% +0.13%
==========================================
Files 517 517
Lines 62542 62636 +94
==========================================
+ Hits 39657 39799 +142
+ Misses 19304 19260 -44
+ Partials 3581 3577 -4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
f0e6f87 to
6f4a4b0
Compare
6f4a4b0 to
a32367c
Compare
a32367c to
a498621
Compare
| if toolsImage == "" { | ||
| return false | ||
| } | ||
| initChanged, ok := onlyKBManagedContainerImageFieldsChanged(oldPod.Spec.InitContainers, newPod.Spec.InitContainers, toolsImage) |
There was a problem hiding this comment.
[P2] This helper treats initContainer image changes as safe in-place updates, but already-completed init containers are not re-executed when their PodSpec image is patched. For init-kbagent, kbagent-worker, or install-config-manager-tool, the controller can bypass a ReCreate policy, patch the spec, and then consider the pod updated even though the init-time tool/binary remains from the old image. Please keep the ReCreate path for initContainer-only KB tools image changes, or otherwise prove that a normal running container restart applies the new tool payload.
a498621 to
4c29af6
Compare
4c29af6 to
834f574
Compare
|
/approve |
Summary
Root Cause
KubeBlocks-managed sidecar/tools image changes were classified as container/initContainer upgrade diffs. When the resolved podUpgradePolicy was ReCreate, the update reconciler converted an otherwise in-place image update into Pod deletion and recreation.
Validation
Fixes #10472