IR-20261111: fix(sbx-gits): emulator memory limit 8Gi → 12Gi (OnDelete — nothing restarts) #946
No reviewers
Labels
No labels
operator-review
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Homelab/infra-core!946
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "plane/IR-20261111-gitsemu"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
sbx-gitsStatefulSet,emulatorcontainer:limits.memory8Gi → 12Gi. The request stays 6Gi. Nothing else changes; one value line plus the sizing comment beside it.Diff (rendered,
kubectl kustomize core/manifests/apps/sbx-gits):Why
The
emulatorcontainer in sbx-gits-0 was OOMKilled at 2026-11-11T20:20:14Z — exit 137 against this very 8Gi limit — during a single screenshot pass at 2000x1250 @280dpi.The guest's RAM is still pinned at
hw.ramSize=3072MB, but qemu, the-gpu swiftshader_indirectCPU rendering at tablet resolution and the page cache from the AVD userdata writes in theemptyDir/avdall count against this container's cgroup, and together they outgrew 8Gi. Earlier, at ~19:4x–19:5x, the same pressure showed up as a transient adb drop with in-guest crashes, below the limit.prod-wk-01 was at 37% actual / 80% requested, so 4 Gi more is affordable, and the request — what the scheduler actually reserves — does not move, so the pod's placement on the node does not change either. The
sandboxcontainer is untouched: T7 does not take margin away from the orchestrators to pay for the guest.homelab-33 agreed to the raise at 2026-11-11T20:22:03Z.
⚠️ OnDelete: NOTHING restarts on merge
This is a StatefulSet with
updateStrategy: OnDelete(verified from the render, not from memory). Merging this PR starts no rollout: the running sbx-gits-0 keeps its 8Gi limit.The new value takes effect only at sbx-gits's next pod recreation, which is timed by homelab-33 with El Director, together with the pending forgejo-ext pin. We never restart sbx-gits ourselves to make this land.
Verification
git diffis exactly two hunks:memory: 8Gi→memory: 12Giunderlimits:of theemulatorcontainer, plus the sizing comment (reason, OOM time, OnDelete note, and the corrected pod totals: limits memory 10Gi + 12Gi = 22Gi).kubectl kustomize core/manifests/apps/sbx-gitsrenders the StatefulSet withemulatorlimitscpu: 12, memory: 12Gi, ephemeral-storage: 16Giand requests2 CPU / 6Giunchanged;sandboxandemu-healthbyte-identical.yamllint -d relaxed core/manifests/apps/sbx-gits/→ 0 errors (the file's pre-existing line-length warnings only; every added line is ≤ 80 columns).resourcesof all three containers read back as above).IR-20261111-gitsemu(Lab-Run: IR-20261111-gitsemu, last trailer).Note (out of scope on purpose)
core/manifests/apps/sbx-gits/README.mdstill documents the emulator as 6Gi/8Gi (§3 table, §3.2 and the prose around "limits memory = 18 GiB"). This change deliberately touches only the manifest value and its own comment. The README rows want a follow-up that also reconciles the rows that are already stale onlive(the README sayssandbox6Gi/10Gi while the rendered StatefulSet is 12Gi/16Gi).APPROVE — ld-reviewer — head
7a2e32d229Reviewed as a diff against base (single hunk,
core/manifests/apps/sbx-gits/statefulset.yaml, 18+/2-) plus the file read at head7a2e32d.emulator.resources.limits.memory: 8Gi -> 12Gi(diff @@ -1368,7 +1384,7 @@);emulator.resources.requests.memorystays6Giandrequests.cpu: "2"/limits.cpu: "12"/ephemeral-storage(8Gi req / 16Gi lim) are untouched. The other two diff lines are the sizing comment beside the value: the new MEMORY LIMIT block (OOM 2026-11-11T20:20:14Z, exit 137, hw.ramSize=3072 MB, OnDelete note) and the pod-totals comment corrected tolimits 10Gi + 12Gi = 22Gi(was 18Gi) withrequests 6Gi + 6Gi = 12Giand6 + 12 = 18 CPUunchanged. No other file, no other key.emulatorcontainer's comment and its memory limit.sandbox(requests 2 CPU / 12Gi / 1Gi, limits 12 CPU / 16Gi / 10Gi) andemu-health(requests 50m / 64Mi, limits 500m / 256Mi) are byte-identical base vs head —diffof the two emu-health blocks is empty and the file diff confirms no hunk reaches either container.spec.updateStrategy.type: OnDelete(statefulset.yaml:182-183), so merging this template restarts nothing; the new limit only appears at sbx-gits's next pod recreation. The PR's central claim holds.Lab-Run: IR-20261111-gitsemu(nothing after it).Non-blocking note (pre-existing, not introduced here, NOT a finding): the unchanged context line "The
sandboxcontainer is UNCHANGED (6Gi/10Gi, 2/6 CPU)" is already stale at base — the manifest hassandboxat 12Gi request / 16Gi limit, 2/12 CPU. It is a context line, unchanged by this PR; worth a later cleanup so the sizing comment does not mislead. Likewise the new phrase "nothing changes for the sandbox" means the emulator's 6Gi request/scheduling, which is accurate.model: omniroute/deepseek-flash
session: IR-20261111-gitsemu-seatA-20261112T0518Z
APPROVE — ld-reviewer — head
7a2e32d229Census seat B. Reviewed the pull diff against merge-base
3563ec7(base tipe3eedc6has moved ahead with IR-20261112-npmcache, so a two-dot diff to the base tip shows an unrelated sandbox-env removal — the author's own delta is the merge-base one) and readcore/manifests/apps/sbx-gits/statefulset.yamlat the head commit.Single value moves, correctly. Only file in the PR (changed_files=1, +18/−2). Hunk
@@ -1368,7 +1384,7 @@:- memory: 8Gi→+ memory: 12Giinside theemulatorcontainer'slimits:(cpu"12"andephemeral-storage: 16Giare context, untouched). The adjacentrequests:block is context only:cpu: "2",memory: 6Gi,ephemeral-storage: 8Gi— the 6Gi request stays, so the scheduler reservation is unchanged. The rest of the delta is the sizing comment in the same block (the new 16-line MEMORY LIMIT rationale plus the pod-totals linelimits 10Gi + 8Gi = 18Gi→limits 10Gi + 12Gi = 22Gi, which is the correct arithmetic for that edit). Whole-file diff merge-base→head reproduces the PR diff exactly; nothing outside theemulatorresources block moves.Orchestrators untouched. Byte-compared the container blocks between merge-base and head:
sandbox372 lines identical,emu-health77 lines identical. Their resources are the pre-existing ones (sandboxrequests 2 CPU/12Gi, limits 12 CPU/16Gi;emu-health50m/64Mi, 500m/256Mi). No margin is taken from them.Claim honesty verified: OnDelete is real. At head,
updateStrategy:→type: OnDelete(line 182–183), so a.spec.templatechange does not roll the pod; the new limit lands only at the next pod recreation. The PR's "merging restarts nothing" holds.Commit trailer: the message ends with
Lab-Run: IR-20261111-gitsemuas its last trailer.README staleness is disclosed in the body and out of scope; not counted as a finding.
Non-blocking, pre-existing (not introduced here, not a hold): the pod-totals comment this PR edits still describes
sandboxas6Gi/10Gi, 2/6 CPU, while the manifest at head hassandboxat 12Gi/16Gi, 2/12 CPU since 2026-11-08. The emulator term the PR touched is right; the sandbox terms were already stale in base. Worth a separate cleanup.model: omniroute/deepseek-flash
session: IR-20261111-gitsemu-seatB-20261112T0518Z