Drain sessions before replacing runtime Pods#1506
Conversation
ab2ef41 to
60e5d3d
Compare
|
/kelos review |
|
🤖 Kelos Task Status Task |
|
🤖 Kelos Reviewer Agent @gjkim42 Review SummaryVerdict: APPROVE Findings Overview
FindingsSecurity
Key takeaways
|
e1b6ed4 to
150f41b
Compare
|
/kelos review |
|
🤖 Kelos Task Status Task |
|
/kelos review |
|
🤖 Kelos Task Status Task |
|
🤖 Kelos Agent @gjkim42 Addressed P1 in the squashed branch update. Session Pod currency uses the StatefulSet controller revision after the StatefulSet controller has observed the current generation, so admission-rewritten runtime images do not trigger repeated drain and replacement. The unit regression covers a digest/mirror rewrite, and the integration/e2e fixtures model StatefulSet revisions. P2 is intentionally declined per maintainer direction. The forced known-idle update is a one-time migration procedure for Sessions created before runtime draining existed, so it remains in this PR's release-note block only and is intentionally not duplicated in |
273a9b6 to
dbd38a4
Compare
|
/kelos review |
|
🤖 Kelos Task Status Task |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Session StatefulSets roll out runtime image changes automatically, which can replace a Pod while it is processing a turn. Kelos must keep the StatefulSet at the desired runtime configuration so failed Pods recover correctly, while allowing healthy Pods to finish accepted work before replacement.
This change coordinates runtime replacement through Session annotations while keeping the StatefulSet at the desired configuration:
OnDelete, and the controller records the desired runtime configuration immediatelyThe request travels entirely through the Kubernetes API; the controller does not exec into Session Pods. The protocol does not add fields to the Session CRD.
Which issue(s) this PR is related to:
N/A
Special notes for your reviewer:
Validation:
make updatemake verifymake testmake test-integration(125 specs)make buildThe E2E suite holds a turn at a user-input request, verifies that the desired StatefulSet is current while the stale Pod remains in place, then verifies that a new Pod is created only after the turn drains.
Does this PR introduce a user-facing change?