Docs: Network volume path guidance, S3 upload, and test workaround#193
Docs: Network volume path guidance, S3 upload, and test workaround#193Jmendapara wants to merge 4 commits into
Conversation
…ns and path configuration details - Added important notes on using relative paths for network storage to avoid model detection issues. - Included a section on uploading files via the S3-compatible API, with detailed command examples and explanations. - Clarified the expected directory structure and provided troubleshooting tips for network volume access during testing.
…del structure - Clarified the usage of relative paths for models on network storage to prevent detection issues. - Updated the section on uploading models via the S3-compatible API with new command examples and path formats. - Adjusted the expected directory structure to reflect changes in model naming conventions.
TimPietruskyRunPod
left a comment
TimPietruskyRunPod
left a comment
There was a problem hiding this comment.
Great docs PR — the path-relative-to-volume-root caveat is exactly the trap users keep hitting. Approve direction.
One outdated reference + missing changeset:
Outdated: the test workaround section says "you can work around this by removing .runpod/tests.json". As of c41432e on main the file was renamed to .runpod/tests_.json precisely so it stops blocking deployments by default (see #201). Please update the wording to reflect that — something like:
RunPod's test environment does not have access to the network volume mount. The repository ships with the tests file renamed to
.runpod/tests_.jsonso they don't run by default; if you've re-enabled them and they fail withValue not in list, remove or rename the file again.
Changeset: please add .changeset/docs-network-volume-guidance.md:
---
"worker-comfyui": patch
---
docs: clarify network-volume path semantics (paths relative to volume root), document S3-compatible upload flow, and note the `.runpod/tests_.json` rename for tests that fail without the volume.Once those two are addressed I'll approve.
Also — the PR is opened from Jmendapara:main to runpod-workers:main, which works but means follow-up commits to your fork's main will land in this PR. Not blocking, just FYI.
- Update test workaround to reflect .runpod/tests_.json rename - Add changeset for the docs change Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 participants
Motivation
Users configuring network volumes were hitting two problems: (1) putting /runpod-volume in paths on the storage led to runpod-volume/runpod-volume/models/... inside the worker and models not being found, and (2) RunPod’s test environment doesn’t mount the volume, so tests that expect /runpod-volume fail or block deployment. There was also no doc showing how to upload models via RunPod’s S3-compatible API.
This PR updates the network volumes doc to:
Clarify that paths on the storage must be relative to the volume root (e.g. /models/loras), not /runpod-volume.
Document that tests don’t see the volume and that removing .runpod/tests.json is a valid workaround when tests block deployment.
Add a short “Uploading files via the S3-compatible API” section with a generic aws s3 cp example and links to RunPod’s S3 API docs for credentials and endpoints.