Skip to content

Send platform as a query parameter on container create - #607

Open
tas50 wants to merge 1 commit into
upserve:masterfrom
tas50:fix-container-create-platform
Open

Send platform as a query parameter on container create#607
tas50 wants to merge 1 commit into
upserve:masterfrom
tas50:fix-container-create-platform

Conversation

@tas50

@tas50 tas50 commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

/containers/create takes platform as a query parameter. Docker::Container.create forwarded only name to the query string and dumped everything else into the request body, so a caller asking for a platform got it placed in the body — where the daemon accepts and silently ignores it.

The bug

QUERY={"name" => "dapi-plat"}
requested linux/amd64 on an arm64 host -> resulting container arch = arm64

Nothing raised. The container just came up on the wrong architecture. This is why kitchen-dokken bypasses the gem entirely and posts to /containers/create by hand.

The fix

Pull the query keys into CREATE_QUERY_KEYS and route both name and platform through it.

Verification

The query parameter now reaches the daemon:

POST /containers/create QUERY={"name" => "dapi-plat3", "platform" => "linux/amd64"}

And the daemon acts on it. With only the amd64 variant of alpine present locally, asking for arm64 is now correctly rejected instead of silently starting an amd64 container:

image with reference alpine:latest was found but does not provide
the specified platform (linux/arm64)

Two specs cover it — one asserting platform reaches the query string, one asserting it is absent from the body. Both were confirmed to fail before the change:

expected: ("/containers/create", hash_including("platform" => "linux/amd64"), anything)
     got: ("/containers/create", {}, {body: "{...,\"platform\":\"linux/amd64\"}"})

62 examples across the container, exec, network, volume and top-level specs pass with the change.

Compatibility

Not a breaking change — platform previously had no effect wherever it was placed, so nothing can be relying on the old behaviour.

CI will be red until #605 lands; this branch is off master, where the workflow is currently broken for unrelated reasons.

/containers/create takes `platform` as a query parameter. Docker::Container.create
forwarded only `name` to the query string and dumped everything else into the
request body, so a caller asking for a platform got it placed in the body, where
the daemon accepts and silently ignores it:

    QUERY={"name" => "dapi-plat"}
    requested linux/amd64 on an arm64 host -> got arm64

Nothing raised. The container simply came up on the wrong architecture, which is
the worst way for this to fail.

Pull the query keys out into CREATE_QUERY_KEYS and route both name and platform
through it. With the fix the daemon actually sees the parameter, and asking for a
platform the local image does not provide now reports that:

    image with reference alpine:latest was found but does not provide
    the specified platform (linux/arm64)

Not a breaking change: `platform` previously had no effect wherever it was
placed, so no caller can be relying on the old behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant