Skip to content

build: device entitlement support#50386

Merged
vvoland merged 1 commit intomoby:masterfrom
crazy-max:build-device-entitlement
Jul 24, 2025
Merged

build: device entitlement support#50386
vvoland merged 1 commit intomoby:masterfrom
crazy-max:build-device-entitlement

Conversation

@crazy-max
Copy link
Member

follow-up:

Adds device entitlement support in Docker daemon configuration. This entitlement is enabled by default to match current behavior in moby when requesting devices.

- Human readable description for the release notes

Add `device` entitlement to builder configuration

- A picture of a cute animal (not mandatory but encouraged)

@vvoland vvoland added this to the 29.0.0 milestone Jul 11, 2025
Copy link
Member

@tonistiigi tonistiigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entitlement is enabled by default to match current behavior in moby when requesting devices.

Wdym by "current behavior" here?

@thompson-shaun thompson-shaun added the release-blocker PRs we want to block a release on label Jul 14, 2025
@thaJeztah
Copy link
Member

Wdym by "current behavior" here?

Slightly curious as well; here's on my current Docker Desktop with v28.3.x

docker buildx inspect
...
Devices:
 Name:                  docker.com/gpu=webgpu
 Automatically allowed: false
...

Does this config relate to the Automatically allowed: false ?

Comment on lines 135 to 139
type BuilderEntitlements struct {
NetworkHost *bool `json:"network-host,omitempty"`
SecurityInsecure *bool `json:"security-insecure,omitempty"`
Device *bool `json:"device,omitempty"`
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably needs changes in the daemon docs, although it looks like we currently don't document these at all? https://github.com/docker/cli/blob/7668b683d2bdd470b6fc95082f4a1f9f3f5c756a/docs/reference/dockerd.md#on-linux

currently only shows this in the example (no docs);

  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "10GB",
      "policy": [
        { "keepStorage": "10GB", "filter": ["unused-for=2200h"] },
        { "keepStorage": "50GB", "filter": ["unused-for=3300h"] },
        { "keepStorage": "100GB", "all": true }
      ]
    }
  },

Comment on lines 548 to 550
if conf.Entitlements.Device == nil || *conf.Entitlements.Device {
ents = append(ents, string(entitlements.EntitlementDevice))
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does BuildKit have some list of its defaults? Slightly starting to wonder if we need to change the BuilderEntitlements to be a map[string]bool (or something) that allows it to stay in sync with whatever new options are added in BuildKit

That may also allow us to validate options as part of dockerd --validate (i.e., check the list of keys against known entitlements in BuildKit)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does BuildKit have some list of its defaults?

They are all disabled by default in buildkit

Slightly starting to wonder if we need to change the BuilderEntitlements to be a map[string]bool (or something) that allows it to stay in sync with whatever new options are added in BuildKit

Yes I think we could but needs to keep current defaults for moby.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, considering we could set some defaults here (which is where we set most defaults);

// New returns a new fully initialized Config struct with default values set.
func New() (*Config, error) {
// platform-agnostic default values for the Config.
cfg := &Config{
CommonConfig: CommonConfig{
ShutdownTimeout: DefaultShutdownTimeout,
LogConfig: LogConfig{
Config: make(map[string]string),
},
MaxConcurrentDownloads: DefaultMaxConcurrentDownloads,
MaxConcurrentUploads: DefaultMaxConcurrentUploads,
MaxDownloadAttempts: DefaultDownloadAttempts,
BridgeConfig: BridgeConfig{
DefaultBridgeConfig: DefaultBridgeConfig{
MTU: DefaultNetworkMtu,
},
},
NetworkConfig: NetworkConfig{
NetworkControlPlaneMTU: DefaultNetworkMtu,
DefaultNetworkOpts: make(map[string]map[string]string),
},
ContainerdNamespace: DefaultContainersNamespace,
ContainerdPluginNamespace: DefaultPluginNamespace,
Features: make(map[string]bool),
DefaultRuntime: StockRuntimeName,
MinAPIVersion: defaultMinAPIVersion,
},
}
if err := setPlatformDefaults(cfg); err != nil {
return nil, err
}
return cfg, nil
}

We may need to look closely if we want to import BuildKit packages there, or define local consts for the defaults (but possibly it's fine to import buildkit code).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly we can inject the defaults as well (I need to refresh my memory on the exact flow we have for these).

@crazy-max
Copy link
Member Author

This entitlement is enabled by default to match current behavior in moby when requesting devices.

Wdym by "current behavior" here?

I meant running a container in moby allows access to specified cdi devices without any specific entitlement atm so I think it should be the same for build.

Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
@crazy-max crazy-max force-pushed the build-device-entitlement branch from 9741d95 to d95dceb Compare July 21, 2025 08:26
@vvoland vvoland merged commit 665eb3a into moby:master Jul 24, 2025
258 of 260 checks passed
@crazy-max crazy-max deleted the build-device-entitlement branch July 24, 2025 14:18
@crazy-max crazy-max self-assigned this Jul 24, 2025
@vvoland vvoland added the kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny label Aug 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/builder/buildkit Build area/builder Build impact/changelog kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny release-blocker PRs we want to block a release on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants