chore: patch metadata-only pod updates#10401
Conversation
After a successful reconfigure, the remaining pod diff can be only config-hash metadata. A full Pod update can conflict with concurrent kubelet/status writes and leave the annotation stale, which keeps the OpsRequest running even after the runtime config changed. Add an explicit ObjectTree patch option and use it for metadata-only in-place pod updates in the InstanceSet and Instance reconcilers.
|
Auto Cherry-pick Instructions CLA Recheck Instructions |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #10401 +/- ##
==========================================
+ Coverage 61.87% 61.97% +0.09%
==========================================
Files 533 533
Lines 63609 63621 +12
==========================================
+ Hits 39360 39427 +67
+ Misses 20661 20618 -43
+ Partials 3588 3576 -12
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:
|
|
Runtime validation update for clean head
Observed gate details:
Boundary: this is exact clean-head validation for the focused Redis Parameters x replication-twemproxy gate. It is not a Redis addon release-ready claim or a broader matrix result. |
|
/cherry-pick release-1.1 |
|
🤖 says: cherry pick action finished successfully 🎉! |
(cherry picked from commit e296fcd)
Problem
Fixes #10369.
After a successful reconfigure, the remaining in-place Pod diff can be only metadata such as the config-hash annotation. Planning that as a full Pod update can race with concurrent status writes and leave the config-hash/status stale, which keeps the OpsRequest running even though the database-side reconfigure action returned OK.
This PR is a clean metadata-only branch based directly on
main. It intentionally does not include the resource-compare cleanup from #10394.Changes
Tests
git diff --check origin/main..HEADgo test ./pkg/controller/kubebuilderx ./pkg/controller/instance ./pkg/controller/instanceset -count=1Runtime status
04f6d7e90770ed07d32a9c9b9435cab45782692d: exact-image Redis Parameters x replication-twemproxy focused gate failed, PASS 14 / FAIL 1 / SKIP 0; OpsRequest stayedRunning; Component/InstanceSet status and config-hash did not converge.31908d0cb7aa64c79c882e6ee71dfbce0e668516: exact-image Redis Parameters x replication-twemproxy focused gate passed, PASS 34 / FAIL 0 / SKIP 0.5c5c2a060d15a7eb2c0e7fb25d640ac7a29ad579: exact-image Redis Parameters x replication-twemproxy focused gate passed, PASS 34 / FAIL 0 / SKIP 0.Clean-head runtime evidence:
kubeblocks:pr-10401-5c5c2a0-stellab25456144e7cceb6ab6e0d1c841521a99c5f8da2bd0fa914278bf690f4d66a89sha256:4102f31aa873f864fe115ceaf6f59b29673be2e861f4902183f1cfe6be7ee56ekubeblocks-785f58d76b-8wd9b, imageIDsha256:f4584d503aba16f3cc28d4057dbba319e6c73a71607d73f94e0314853bdb51d1, startTime2026-06-18T06:17:34Z, restartCount 0redis-pr10401-5c5c2a0-parameters-twemproxy-20260618T1411.tgz, sha256bd3ebe3a2e91e9e0741fad0f80f5b31940fcb0390e1498006818296c5f4b863fObserved clean-head gate details:
maxmemory-policy: OpsRequestSucceed, ConfigMap updated, both Redis pods read backallkeys-lru, pod UIDs unchanged, twemproxy SET/GET OK.hz: OpsRequestSucceed, both Redis pods read back50, pod UIDs unchanged, twemproxy SET/GET OK.databases: OpsRequestSucceed, both Redis pods read back32, pod UIDs changed as expected, twemproxy SET/GET OK.Boundaries