What happened
After #10758, InstanceSet status reconciliation still has a two-reconcile handoff when a new spec generation arrives: StatusReconciler is intentionally ordered before RevisionUpdateReconciler and waits until the new desired revisions are published. During that handoff, an existing InstanceStatus.UpToDate=true can survive even when the new generation changes that instance's desired Pod, dynamic config, or PVC expansion target.
A rolling Ops consumer can therefore observe the new InstanceSet observedGeneration together with stale per-instance convergence.
Expected behavior
- do not clear UpToDate for every instance on every generation
- invalidate only existing Active/Present instances affected by a Pod update, dynamic config change, or PVC expansion
- preserve observations for unaffected instances
- keep add/remove/offline/released represented by DesiredState and CurrentState
- keep legacy ITS and ITS2 public status semantics aligned
- do not add generation fields or reorder StatusReconciler and RevisionUpdateReconciler
Scope
This issue covers the workload status producers only. Ops consumption remains owned by #10760.
What happened
After #10758, InstanceSet status reconciliation still has a two-reconcile handoff when a new spec generation arrives: StatusReconciler is intentionally ordered before RevisionUpdateReconciler and waits until the new desired revisions are published. During that handoff, an existing InstanceStatus.UpToDate=true can survive even when the new generation changes that instance's desired Pod, dynamic config, or PVC expansion target.
A rolling Ops consumer can therefore observe the new InstanceSet observedGeneration together with stale per-instance convergence.
Expected behavior
Scope
This issue covers the workload status producers only. Ops consumption remains owned by #10760.