Originally filed in BimRoss/rancher-admin#203 — moved here per Grant. Closing the rancher-admin one in favor of this.
Why
The default Ross pod is capped at 3 GB RAM / 1 CPU core / no GPU, which is fine for normal coding/admin tasks but tight-to-painful for audio + ML workloads. First real example: the Matt Wood piano sampler project (#1) — ~1.8 GB of 24/48 stereo WAVs, CREPE pitch detection across ~500 slices, SFZ generation. Doable in-pod via streaming, but slow and constrained.
This will recur. Likely future loads:
- More sample libraries (other instruments, future Matt projects, contributors).
- Audio transcription / source separation (Demucs, Spleeter).
- Any embedding / small-model inference work that doesn't justify a managed service.
Ask
Stand up a small opt-in node pool / namespace in the cluster sized for these jobs. Doesn't need to be on all the time — should scale down to zero when idle. Spec sketch:
- RAM: 16-32 GB per node (CREPE + audio loads comfortably).
- CPU: 4-8 cores.
- GPU: optional but nice (T4 / L4 class) — lets CREPE, Demucs, future Whisper-style work run in seconds instead of minutes. Skip if cost is meaningful; CPU works.
- Storage: scratch volume per job (50-100 GB), ephemeral. Sources pulled from Drive / object storage per-run.
- Autoscaling: scale-to-zero when idle. Spin up on demand via a job manifest or a tiny CLI (
ross-audio run <repo> <command>).
Access pattern
Rather than giving Ross-the-agent a permanently bigger pod (which would inflate normal-task costs), make this a job runner Ross can call:
kubectl create -f audio-workbench-job.yaml style, or a wrapper that templates it.- Ross posts the job, the cluster runs it, output lands in a known volume / GCS bucket / artifact directory.
- Logs stream back so progress is observable.
Out of scope for v1
- Multi-tenant queueing (one-job-at-a-time fine to start).
- Web UI / dashboard (kubectl + Slack updates from Ross is plenty).
- Managed Argo/Tekton/etc. — overkill, plain Job + ConfigMap is fine until proven otherwise.
Status / priority
Not urgent. Bubby's Piano ships fine in-pod via streaming. File this so we have the right shape ready when the second audio project lands, or when CREPE on full files becomes a bottleneck.
Linked: #1
Why
The default Ross pod is capped at 3 GB RAM / 1 CPU core / no GPU, which is fine for normal coding/admin tasks but tight-to-painful for audio + ML workloads. First real example: the Matt Wood piano sampler project (#1) — ~1.8 GB of 24/48 stereo WAVs, CREPE pitch detection across ~500 slices, SFZ generation. Doable in-pod via streaming, but slow and constrained.
This will recur. Likely future loads:
Ask
Stand up a small opt-in node pool / namespace in the cluster sized for these jobs. Doesn't need to be on all the time — should scale down to zero when idle. Spec sketch:
ross-audio run <repo> <command>).Access pattern
Rather than giving Ross-the-agent a permanently bigger pod (which would inflate normal-task costs), make this a job runner Ross can call:
kubectl create -f audio-workbench-job.yamlstyle, or a wrapper that templates it.Out of scope for v1
Status / priority
Not urgent. Bubby's Piano ships fine in-pod via streaming. File this so we have the right shape ready when the second audio project lands, or when CREPE on full files becomes a bottleneck.
Linked: #1