GOV-NB-001 — Enforce and observe connected-idle kernel culling
| Field | Value |
|---|---|
| Status | Open operations validation; source-configured |
| Architecture state | Source-backed deployment policy; deployed values pending capture |
| Severity | High cost exposure |
| Affected surface | Idle notebook kernels, closed browser tabs, and orphan Spark workloads |
| Components | sparqd/platform-stacks, JupyterHub, Enterprise Gateway, Spark runtime |
| Associated issue | project-management #1349 |
Where the problem appears
Leave a disposable kernel connected but inactive beyond the configured idle period, including after closing its browser tab, and observe cleanup.
Concrete observed case
Deployment source records an earlier condition where a closed browser left a connected kernel idle for more than 45 minutes. The current configuration makes connected but inactive kernels eligible for culling after 1,800 seconds, with a periodic check approximately every 300 seconds.
Expected condition
Idle kernels and their Spark workloads are removed within the documented window, active kernels are retained, the UI explains expiry on reconnect, and operators detect orphaned or repeatedly replaced workloads.
Cause and evidence
A per-user Jupyter Server can keep its gateway channel connected after the browser closes. Without connected-idle culling, connection presence prevents cleanup even when no user computation remains.
Why it matters
Every retained Spark kernel holds a driver and at least one executor, creating ongoing compute and storage cost without visible user activity.
Existing controls and workarounds
JupyterHub and Enterprise Gateway share the 1,800-second idle policy, and the gateway performs the server-side idle decision. The browser should reconcile on load, reconnect, or channel closure rather than continuously polling.
Alternatives considered
- Recommended: server-side connected-idle culling plus orphan metrics and alerts.
- Cull only disconnected kernels — rejected because the user server can keep a channel connected after the browser leaves.
- Browser-driven cleanup — rejected because browsers are not reliable lifecycle authorities.
Component involvement
sparqd/platform-stacksowns the coordinated idle policy.- Enterprise Gateway performs kernel idle evaluation and cleanup.
- JupyterHub manages user-server idleness.
- Operations detects orphan SparkApplications and policy drift.
Reproduction and verification
Follow NB-S007.
Resolution conditions
Close when deployed values are captured, active/idle cases are proven, orphan alerts work, and cleanup removes the kernel and Spark resources within the agreed tolerance.
Validation and blockers
The configuration and prior operational observation are source-backed. A full idle-window test and observability capture remain pending.