Repository navigation
Conversation
|
/test ? |
|
Important Review skippedWe couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review. WalkthroughThe kube-apiserver ChangesShutdown delay
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Change: Other Merge Risk: ⚪ Minimal · up to The one-second shutdown delay is not shown to violate a repository-defined traffic-drain requirement, so no concrete merge-blocking risk is established. 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Skipping CI for Draft Pull Request. |
|
/test e2e-aws-tests-bootc-el9 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pacevedom The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
shutdown-delay-duration tells the apiserver how long to keep serving after receiving SIGTERM before it stops accepting new requests. Its value is a plain time.Sleep with no short-circuit, so it is spent in full on every shutdown. MicroShift's graceful shutdown budget is 15s, so a 5s delay consumed a third of it before any teardown work began. That delay exists in multi-node OpenShift to let load balancers and endpoint controllers route clients to another apiserver (the upstream default is 70s). Single-node MicroShift has no second apiserver and no HA load balancer to drain to, so the delay provides little benefit while eating budget that the apiserver's own teardown needs. Reduce it to 1s, which keeps a small graceful window (clients still get a Retry-After) while reclaiming ~4s per shutdown. Typical stops drop from ~8s to ~3s. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The kube-apiserver's post-delay teardown (in-flight drain, HTTP server shutdown, post-shutdown hooks) can occasionally take ~16-18s under CPU contention, exceeding the 15s graceful shutdown budget. When that happens MicroShift force-exits mid-shutdown and logs "MICROSHIFT STOP TIMED OUT", which trips the standard2 Log Scan test's "Services Should Not Timeout When Stopping" check and causes intermittent CI failures. The timeout is a ceiling, not a fixed wait: clean shutdowns still exit as soon as all services stop (~3s with the 1s shutdown-delay-duration), so this only gives the rare slow teardown room to finish gracefully instead of being killed. 30s stays well under systemd's default TimeoutStopSec, so there is no risk of a premature SIGKILL. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
b100bd7 to
3a39dfd
Compare
|
/test e2e-aws-tests-bootc-el9 |
|
@pacevedom: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Summary by CodeRabbit