Problem
On release-1.0 and release-1.1, a previous Restart OpsRequest can cause a later file-template configuration change to lose its restart signal. This was reported with KubeBlocks 1.0.3-beta.13 during RustFS/MinIO horizontal scaling: existing replicas can retain their old process configuration while new replicas start with the expanded configuration.
Reproduction
- Use a component with a config template that enables
restartOnFileChange.
- Complete a Restart OpsRequest. Its timestamp T0 remains in the component annotations in the Cluster spec.
- Change a template variable, for example by scaling the component so the rendered config changes.
- The component controller writes a newer timestamp T1 to
InstanceSet.spec.template.annotations["kubeblocks.io/restart"].
- On the next reconciliation, the ConfigMap already contains the desired data. The rebuilt pod template carries T0 from the Component spec and overwrites T1.
The restart signal can disappear before the workload controller finishes consuming it. Two concurrent Restart OpsRequests are not required; rollout behavior depends on reconciliation timing.
Expected behavior and fix
Merge valid RFC3339 restart timestamps by retaining the later instant. Preserve the existing representation for equal instants, and retain existing annotation merge behavior when either value is not a timestamp. A subsequent newer Restart OpsRequest must still propagate.
Apply this fix to release-1.1 and verify automatic picking to release-1.0. Main uses config hashes and spec.configs[].restart for config-driven restarts, so this conflict does not occur on that path. The separate parameters-controller config.kubeblocks.io/restart-* annotations are outside this defect.
Validation
- Regression cases for older/newer timestamps, equal instants, timezone offsets, fractional seconds, missing values, opaque values, and repeated reconciliation.
- Component controller integration tests for config-triggered restart after an earlier explicit restart, retaining the signal, and accepting a subsequent explicit restart.
- Local pick and equivalent tests on release-1.0.
Related report: https://github.com/apecloud/apecloud/issues/20826
Tracking
Problem
On release-1.0 and release-1.1, a previous Restart OpsRequest can cause a later file-template configuration change to lose its restart signal. This was reported with KubeBlocks 1.0.3-beta.13 during RustFS/MinIO horizontal scaling: existing replicas can retain their old process configuration while new replicas start with the expanded configuration.
Reproduction
restartOnFileChange.InstanceSet.spec.template.annotations["kubeblocks.io/restart"].The restart signal can disappear before the workload controller finishes consuming it. Two concurrent Restart OpsRequests are not required; rollout behavior depends on reconciliation timing.
Expected behavior and fix
Merge valid RFC3339 restart timestamps by retaining the later instant. Preserve the existing representation for equal instants, and retain existing annotation merge behavior when either value is not a timestamp. A subsequent newer Restart OpsRequest must still propagate.
Apply this fix to release-1.1 and verify automatic picking to release-1.0. Main uses config hashes and
spec.configs[].restartfor config-driven restarts, so this conflict does not occur on that path. The separate parameters-controllerconfig.kubeblocks.io/restart-*annotations are outside this defect.Validation
Related report: https://github.com/apecloud/apecloud/issues/20826
Tracking
bfc84756dpicked cleanly onto5acf307d6; the same regression and Component controller integration tests and package lint passed. PR fix: preserve newer restart timestamps #10911 haspick-1.0, so the repository will create the backport after merge. No separate manual PR is needed at present.