@dnephin. Updated (but not the location of where it's set - see my comment above).

I was being silly - I JSON encoded it instead to preserve structure. And used the OCI image-spec structure to match what @stevvooe has been working on in https://github.com/containerd/containerd/pull/1403/files for example.

So it now will return something like: Supported-Platforms: [{"architecture":"amd64","os":"windows"},{"architecture":"amd64","os":"linux"}]

Thinking a little more - maybe Supported-Runtime-Platforms rather than Supported-Platforms to indicate that it's specifically for running containers. For multi-stage build, assuming the entire set of work is completed to make the daemon fully multi-platform/arch aware everywhere, you could still have a build stage which just does a COPY for example.

Input welcome 😄

@tonistiigi too.

What's the use case for this? The linked issue talks about detecting if a flag is supported but this can be done with a version identifier like for any other new feature.

@tonistiigi It's based on #34617 (comment), the second part by @dnephin:

"The CLI should hide the --platform flag when it's connecting to any daemon that doesn't support multi-platform. This is similar to how we handle experimental features, and features that exist in a newer version of the API (API downgrading). The daemon should return a Is-Multi-Platform header on _ping so the cli can hide these flags."

Problem with hiding the --platform flag is that it makes valid code snippets from windows not work in linux. For example, lcow user adds documentation for their image and it needs to be pulled for linux platform, so the docs will say docker run --platform=linux ... Then a linux user copies that snippet and tries to run it, but fails because there is no platform flag in their system.

Problem with hiding the --platform flag is that it makes valid code snippets from windows not work in linux.

Not true. Hidden doesn't mean it's an error to provide it, it just doesn't show up in --help or usage. If a user provides the flag it will still be accepted and sent to the server.

That's not how the experimental and version annotations work that were used as an example. Why is this case special? We have tens of flags that are platform specific and even more that depend on a feature being available on a node. They are validated during the request, not with a ping.

That's not how the experimental and version annotations work that were used as an example.

It is how they are implemented: https://github.com/docker/cli/blob/d861a1c3ddd794cd64d6c2efb722d7d33391ead7/cmd/docker/docker.go#L211-L237 . We hide them, we don't remove the flag entirely.

However, apparently we also do another check and error out here (https://github.com/docker/cli/blob/d861a1c3ddd794cd64d6c2efb722d7d33391ead7/cmd/docker/docker.go#L245-L271). This is probably because in these cases the daemon will either 1) completely ignore the flag, or 2) report 404 if the API endpoint doesn't exist. In these cases it's better to offer the user an error on the client side because the API doesn't do the right thing.

In the case of platform we don't need to (and shouldn't) error from the client, because specifying a platform that matches a default is a no-op, not an error. Hidding the flag is sufficient. So we can add the platform flags to hideUnsupportedFeatures(), but not to isSupported()

We have tens of flags that are platform specific... They are validated during the request

This is a problem we've already started to fix. From the linked code you can see we have started to hide features by API OSType.

Long out-of-date. Closing as I am no longer working in this area.