Add bnd section to Truss config by yunzou-baseten · Pull Request #2624 · basetenlabs/truss

yunzou-baseten · 2026-08-24T00:45:31Z

Summary

add a typed bdn.mounts configuration section using BDNVolumeMount
accept BDN head, tag, and digest references
reject mount sources that do not use the bdn:// scheme
normalize absolute mount paths and reject duplicate destinations
update the generated configuration schema and validation coverage

bdn:
  mounts:
    - source: bdn://weights/some-model:mytag
      path: /models/some-model

Testing

uv run pytest truss/tests/test_config.py -q (271 passed)
uv run ruff check truss/base/truss_config.py truss/tests/test_config.py
uv run ruff format --check truss/base/truss_config.py truss/tests/test_config.py
uv run mypy truss/base/truss_config.py truss/tests/test_config.py
uv run bin/generate_truss_config_schema.py --check

CLAassistant · 2026-08-24T00:45:37Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

Copilot

Pull request overview

Adds first-class volumes support to TrussConfig, including typed parsing/validation for BDN volume mounts and per-namespace access capabilities, and updates the generated JSON schema and tests accordingly.

Changes:

Introduces VolumeMount, Volumes, and VolumeAccessMode models and wires volumes into TrussConfig.
Extends config.schema.json with the new volumes definitions and top-level property.
Adds YAML parsing + round-trip serialization tests and validation coverage for mounts/access.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
truss/base/truss_config.py	Adds `volumes` models, validation, and a new `TrussConfig.volumes` field.
truss/config.schema.json	Adds schema defs for volumes-related types and exposes `volumes` on the root schema.
truss/tests/test_config.py	Adds YAML parsing/round-trip and validation tests for the new volumes config.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

yunzou-baseten · 2026-08-24T17:33:27Z

+class VolumeAccessMode(str, enum.Enum):
+    """Permissions granted to a model for a BDN volume namespace."""
+
+    PULL = "pull"


@stevvooe @kofmangregory there was a unmatched description about the access mode requirement [read, publish] vs [pull, push, tag, etc], i am staying consistent with the bdn scope here? I am also wondering do we have any plan to change the capbility, if yes, it might be easier to just accept arbitrary str instead of an enum?

cretz · 2026-08-24T18:49:34Z

+    )
+    access: dict[str, list[VolumeAccessMode]] = pydantic.Field(
+        default_factory=dict,
+        description="Namespace names mapped to BDN volume operation scopes.",


What is a namespace? I can't find this in any docs, API, etc but I may be missing it

added description

cretz · 2026-08-24T18:51:20Z

+    return str(mount_path)
+
+
+class VolumeAccessMode(str, enum.Enum):


Can you describe these a bit better? I'm familiar w/ fs mount options, but not familiar with pull, push, tag, etc.

I added more description about what are the namespaces, volume and tags in the comments. we currently don't have any public facing doc description yet. please help take a look and see if it make sense

cretz · 2026-08-25T15:52:32Z

+    These are registry permissions, not filesystem mount options: they govern
+    what the deployment may ask the BDN volume service to do, and mirror the


they govern what the deployment may ask the BDN volume service to do

I am still not following exactly. How does the user's deployment ask the the BDN volume service to do things? Say I have a deployment, can you give be an example of how I can leverage "push" or "tag"? (pardon my ignorance)

those are volume operations performed during the operation of a deployment, as far as i know, there are two ways that an volume operation can be performed:

chowder agent, it lives on the deployment node, and knows the volume protocol and can talk to bdn sevrvice

cannery cli if installed, can be used to talk to bdn service with valid token
cc @stevvooe @kofmangregory please correct me if I am wrong

Hrmm, I may not understand in enough detail, but I would expect what you can/can't do to a volume is a product of restrictions of auth/client and not something about a model deployment. I assume whatever you can do to a volume in container you can do out of container right? So do we really need in container specific approach here?

This allows the deployment itself to push/pull volumes at runtime. They can be hotloaded through a local pod API and mounted to the local filesystem or pushed from local data.

I guess I don't understand exactly, why wouldn't they use the same tools in-container runtime as they might out of container? What does it look like to push a volume at runtime from my container? Not the Baseten CLI they may be familiar with? I can understand it may seem convenient to say "if it came from internal IP, apply different auth", but the concern is that they'd still have to go back to the CLI to do lots and lots of other stuff (e.g. list volumes maybe?), and the other concern is that our permission model for accessing this information should be consistent no matter caller location (especially as we add advanced auth things).

Having said that, technically no strong objection for a just-for-some-calls-and-just-for-in-container different auth approach than otherwise. It can save them from providing auth themselves (which they do have to do for other Baseten API usage from inside container) and maybe there are optimized network routes if a different tool is used.

cretz · 2026-08-25T15:54:39Z

+    source: Annotated[str, pydantic.StringConstraints(min_length=1)] = pydantic.Field(
+        ...,
+        description="Volume to mount. Either a BDN reference (bdn://weights/llama-8b:prod) "
+        "or an external URI using hf://, s3://, gs://, azure://, r2://, cw://, or https://.",
+    )
+    dest: Optional[str] = pydantic.Field(
+        default=None,
+        description="BDN volume the external source is ingested into, as "
+        "bdn://namespace/volume[:tag]. Required for external sources, and not "
+        "permitted when source is already a bdn:// reference.",
+    )


It looks like this changed a bit since I last read. So does this concept of "external source" effectively amount to changing truss push to be server-side truss volume push + truss push? And we're sure we want to combine those concepts? What is the benefit to me as a user being forced to provide this destination if I just want my S3 bucket mounted? I may never use this destination or even care it is BDN backed correct?

Finally, if I did want to push an s3:// source to a bdn:// destination not-specific to this one model (so I could use it across models) could I do so leveraging whatever server-side mechanisms this is going to leverage? Or must I make a fake Truss model and push it to do this data transfer?

sorry, that is out dated. there is a discussion going on to discuss how to expose the support of remote source to customer.
One approach is to introduce a truss volume command to also build a volume out of remote source first, and then use bdn volume in the config. which i think would provide the capability you mentioned that a user just want to push the remote source to a bdn volume and not associated with any model.

For now, i removed the capability, and will handle it later once we are aligned on the support

cretz · 2026-08-26T12:43:11Z

+    mounts: list[VolumeMount] = pydantic.Field(
+        default_factory=list,
+        description="Existing BDN volumes to mount when the model starts.",
+    )
+    hotload: dict[str, list[HotloadAccessScope]] = pydantic.Field(
+        default_factory=dict,
+        description="BDN namespaces mapped to operations available through hot load.",
+    )


Did something change where these are no longer under volumes? If this new "hotload" concept specific to volumes, would recommend both it and mounts is under a volumes section so as not to pretend "hotload" is something general (we do have a concept of "hot reload" on models).

yes, we discussed this part yesterday, and decided to update access -> hotload to indicate clearly those are the namespaces and scopes that can be accessed for hotload. I think that is a new concept, in short refers operations performed by the deployment, we might have to work on the documentation. i also updated the description little bit, hope it is more clear

That is more clear, thanks! It sounds like "hotload" is a volumes-specific concept not a general Baseten one (that can be confused with "hot reload"). I wonder if we can move mounts and hotload under a volumes area? This will also give you a place to add more fields as they come up as opposed to every new non-mount/hotload volume thing being top-level.

cc @kofmangregory @stevvooe

yunzou-baseten · 2026-08-26T17:13:06Z

        default_factory=lambda: Weights([]),
        description="Configure Baseten Delivery Network (BDN) for model weight delivery with multi-tier caching.",
    )
+    mounts: list[VolumeMount] = pydantic.Field(


@stevvooe @kofmangregory , @cretz mentioned that we should bring back the top level volume section back, so that we can group all configuration related to bdn under the same section.
i recall we decided to remove the top level since mounts and hotload two different things. i think have a top-level section to group all configuration is a good practice, so that we can add any future related config under the same section, maybe instead of volume, we can use other top-level section name like bdn? want to bring it up here and see what is your opinion here?

i like a top-level section to contain all volume-related config settings. we are not putting this in config.yaml though, right?

This is config.yaml we're discussing (this model is the schema, eventually a JSON schema, doc'd at https://docs.baseten.co/reference/truss-configuration, generated in SDKs e.g. https://pkg.go.dev/github.com/basetenlabs/baseten-go@v0.2.0/client/modelconfig#ModelConfig, etc). We are encouraging all new features/products to have their own config sections to allow them to add fields in the future and have them be properly qualified/namespaced separate from the rest of the potentially-unrelated config.

yunzou-baseten requested a lite review from Copilot August 24, 2026 16:13

Copilot started reviewing on behalf of yunzou-baseten August 24, 2026 16:13 View session

Copilot AI reviewed Aug 24, 2026

View reviewed changes

Comment thread truss/base/truss_config.py

Comment thread truss/base/truss_config.py Outdated

yunzou-baseten marked this pull request as ready for review August 24, 2026 17:14

yunzou-baseten commented Aug 24, 2026

View reviewed changes

yunzou-baseten requested review from kofmangregory, ndeepak-baseten and stevvooe August 24, 2026 17:33

cretz reviewed Aug 24, 2026

View reviewed changes

yunzou-baseten force-pushed the yzou/truss-config-volumes branch from 76a77e0 to 0306876 Compare August 24, 2026 21:19

cretz reviewed Aug 25, 2026

View reviewed changes

ndeepak-baseten approved these changes Aug 25, 2026

View reviewed changes

yunzou-baseten force-pushed the yzou/truss-config-volumes branch from 345fc85 to 27fda6d Compare August 26, 2026 06:26

cretz reviewed Aug 26, 2026

View reviewed changes

yunzou-baseten requested a review from cretz August 26, 2026 16:48

yunzou-baseten commented Aug 26, 2026

View reviewed changes

yunzou-baseten added 12 commits August 28, 2026 11:46

Add volumes section to Truss config

49e5677

Align volume access with BDN scopes

fc1ff31

Support all BDN volume access scopes

badd192

Support multiple volume access scopes

8b2615d

Validate tagged BDN volume references

3df6b4f

Use regex for BDN volume references

d3a1f06

Normalize volume mount paths

3906628

Support BDN head tag and digest references

0bdb45c

Support BDN inspect volume access scope

1773e2e

Support external volume sources ingested into BDN

070cbdf

add support for external volume and comment

8cc122b

Restore external volume support lost in 84d43ff

5a31015

yunzou-baseten added 7 commits August 28, 2026 11:46

Simplify internal volume auth error message

d2dc6da

Update volume mount config schema

ff3aae8

Rename hotload access mode to scope

e91e3c7

Clarify hot-load access description

2322b0a

add comments

1a6bb7d

Regenerate Truss config schema

cbc021a

Nest volume mounts under BDN config

6ae63a1

yunzou-baseten force-pushed the yzou/truss-config-volumes branch from 6b1813d to 6ae63a1 Compare August 28, 2026 18:52

yunzou-baseten added 5 commits August 28, 2026 11:53

Align hotload access scope values

8351248

Remove hotload configuration

cdc33d1

Rename BDN mount destination to path

2f5e6ab

Rename volume mount model to BDNVolumeMount

081ecaa

Validate BDN digest prefix length

a51d34e

cretz approved these changes Aug 28, 2026

View reviewed changes

kofmangregory approved these changes Aug 28, 2026

View reviewed changes

yunzou-baseten changed the title ~~Add volumes section to Truss config~~ Add bnd section to Truss config Aug 28, 2026

yunzou-baseten merged commit 9f4fa95 into main Aug 28, 2026
36 of 37 checks passed

yunzou-baseten deleted the yzou/truss-config-volumes branch August 28, 2026 20:55

		return str(mount_path)


		class VolumeAccessMode(str, enum.Enum):

		These are registry permissions, not filesystem mount options: they govern
		what the deployment may ask the BDN volume service to do, and mirror the

Uh oh!

Conversation

yunzou-baseten commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Uh oh!

CLAassistant commented Aug 24, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretz Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretz Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretz Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretz Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

yunzou-baseten commented Aug 24, 2026 •

edited

Loading

cretz Aug 26, 2026 •

edited

Loading

cretz Aug 26, 2026 •

edited

Loading

cretz Aug 25, 2026 •

edited

Loading

cretz Aug 26, 2026 •

edited

Loading