runpod: a configured global volume must not fail every pod (v0.3.2)
Probed every API surface coderai can use for attaching a global volume, each
with a body valid enough that the extra-key check actually runs:
POST /v1/pods key … not in input schema: 'globalNetworkVolumeId'
podFindAndDeployOnDemand field not defined by the input type
POST /v2/pods additional properties 'globalVolumeId' not allowed
templates (mounts) every candidate key refused
There is no public API for it: global volumes are console-only, as the docs
say. Which makes `global_volume_id` a loaded gun — sending the field fails the
create, so configuring a global volume would have stopped the install renting
pods at all.
Both create paths now recognise that specific rejection, drop the field and
retry. The pod boots without the volume and downloads its weights: slower and
it costs bandwidth, and far better than serving nothing. Logged once per
process, naming the consequence and the override to set when RunPod publishes
the field name. An unrelated failure is NOT treated this way — a capacity error
retried with the volume stripped would bring a pod up silently wrong.
Earlier probes that reported the field as "accepted" were wrong: with an
otherwise-invalid body the validators stop before the extra-key check. Worth
remembering next time I probe a schema.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment