runpod: a keep_warm pod that is disabled, unnamed or out of hours (v0.2.94)
Configuring the Digesta catalogue on the production orchestrator turned up three
faults in warm_configured_pools, all of which spend money:
* `enabled: false` was not consulted. A catalogue entry parked for later with
keep_warm still set rented a GPU at every boot.
* the entry was named `alias or path`. A RunPod-only entry has neither — no
weights live on that machine, and an alias only exists when a second name is
wanted — so it warmed under the key "" and the pool was never the one that
went on to serve requests. `id` is now the fallback, and an entry with no
name at all says so instead of warming nothing quietly.
* the schedule was ignored. ensure_ready() is the "a request is waiting" path
and provisions unconditionally; at boot nothing is waiting, so a restart at
02:00 on a Sunday rented exactly the pod the window exists to avoid. It now
checks effective_min_pods first, which also means a client lease that
outlives a restart is honoured rather than dropped.
Found on the host, not by reading: the warm pod the configuration asked for
never appeared.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment