Skip to content

fix(k8s): use k8s-native resource quantity units in default manifest - #143

Merged
brettchien merged 1 commit into
mainfrom
fix/k8s-manifest-resource-units
Sep 5, 2026
Merged

fix(k8s): use k8s-native resource quantity units in default manifest#143
brettchien merged 1 commit into
mainfrom
fix/k8s-manifest-resource-units

Conversation

@brettchien

Copy link
Copy Markdown
Contributor

Summary

Root cause of the Hera pod (namespace openab-studio) sitting in Pending forever with Restarts=0 since this morning's fleet-name-collision incident (see #142).

build_default_k8s_manifest (crates/studio-cp/src/lib.rs) reused the ECS Fargate CPU-unit/MiB default values ("256"/"512") that build_default_manifest (the ECS-path sibling) uses. Those bare numbers are a valid, meaningful convention on the ECS side — manifest.rs's VALID_ECS_CPU whitelist is exactly ["256", "512", "1024", "2048", "4096"], Fargate's CPU units (256 = 0.25 vCPU).

k8s has no such convention. resource_requirements() (crates/oabctl/src/k8s_driver.rs) feeds resources.cpu/.memory straight into a k8s Quantity with no ECS-aware conversion — an unsuffixed "256" parses as 256 whole CPU cores, and "512" as 512 bytes. A pod requesting 256 cores can't be scheduled on any real node, so it sits in Pending indefinitely (Restarts=0 because it never gets past scheduling to even pull the image).

manifest.rs's validate() doesn't catch this: the ECS CPU whitelist check only runs for Runtime::Ecs; for Runtime::Kubernetes it explicitly defers ("K8S: cpu/memory format validated at deploy time by K8S API") — the default builder just never emitted k8s-shaped values for that deferred check to actually validate.

Fix

build_default_k8s_manifest's defaults now use k8s-native quantity strings, sized to the same ~0.25 vCPU / 512Mi as the Fargate default:

cpu: "250m".to_string(),      // was "256" → 256 whole cores
memory: "512Mi".to_string(),  // was "512" → 512 bytes

This is the provision_agent_k8s wizard path (the "New fleet" k8s flow) — exactly what created Hera.

Not fixed here

  • The already-live Hera pod is still Pending with the old bad resource request baked into its Deployment spec — this PR only fixes new provisions going forward. Brett will need to redeploy/recreate Hera (or manually patch the Deployment's resources) to pick this up; the pod won't self-heal.

Test plan

  • New regression test k8s_manifest_resources_carry_k8s_unit_suffixes asserting the k8s manifest's cpu/memory carry k8s unit suffixes
  • cargo test -p studio-cp --lib — 34/34 passing

build_default_k8s_manifest copied the ECS Fargate CPU-unit/MiB defaults
("256"/"512") used by the ECS path's build_default_manifest. k8s
Quantity has no such bare-number convention: resource_requirements()
(k8s_driver.rs) feeds these straight into a Quantity, so an unsuffixed
"256" cpu request means 256 whole cores (not 0.25 vCPU) and "512"
memory means 512 bytes (not 512Mi) — unschedulable on any real node.
This is why a freshly provisioned k8s instance (Hera, via the "New
fleet" wizard's provision_agent_k8s path) sat in Pending forever with
0 restarts: it never got past scheduling.

manifest.rs's validate() already only enforces the ECS CPU whitelist
for Runtime::Ecs and explicitly defers k8s cpu/memory format checking
to "K8S API at deploy time" — the default builder just never emitted
k8s-shaped values for that deferred check to catch.

Fix: use k8s-native quantity strings ("250m"/"512Mi") sized to the
same ~0.25 vCPU / 512Mi as the Fargate default.
@brettchien
brettchien merged commit 66a3730 into main Sep 5, 2026
2 checks passed
@brettchien
brettchien deleted the fix/k8s-manifest-resource-units branch September 5, 2026 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant