One character on top of the capacity experiment, and the only difference from
it: the three sandbox nodes go back to 8 vCPUs each, 24 vCPU threads against
the runner's 16 physical cores, 1.5x oversubscribed. Everything else stays as
the parent branch has it, including the trimmed platform, the pinned suite
list and the capacity preflight.
The parent branch changed two things at once and cannot separate them. It cut
oversubscription from 1.5x to 0.75x AND cut pod CPU requests from 16810m to
7310m, then all four tenant workers reached Ready in 50s to 2m36s against a
29 minute deadline, where previously none reached Ready at all. Both changes
reduce contention, so that run supports the capacity hypothesis without saying
which half carried it.
This arm holds the workload trim fixed and restores only the oversubscription:
workers fail to join -> oversubscription is the cause, and the fix is a
bigger runner or fewer sandbox vCPUs, neither of
which is ours to make unilaterally
workers join -> the workload was the cause, the trim is the fix,
and it needs nobody's approval
The capacity preflight is expected to read about 61% either way, since
allocatable triples while requests stay put, so it will not fail this arm.
That is intentional: the preflight guards against Insufficient cpu, not
against oversubscription, and the two are independent here.
hack/sandbox-runner-headroom.bats parses the -smp value out of
hack/e2e-prepare-cluster.bats and passes at 8, 13 assertions.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Myasnikov Daniil
c9f7491b41