Multi-platform tags don't work correctly for Windows client

[richlander]

Perhaps we're doing it wrong.

C:\>ver

Microsoft Windows [Version 10.0.22621.1265]

C:\>docker run --rm mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022 cmd /c "ver"

Microsoft Windows [Version 10.0.20348.1547]

C:\>docker run --rm mcr.microsoft.com/dotnet/runtime:6.0 cmd /c "ver"

Microsoft Windows [Version 10.0.17763.4010]

That's not the behavior we want, right? The .NET multi-platform tag is servicing up a Windows 1809 image, as opposed 2022. I'm on a 22H2 host system.

Should we be guiding users to not use multi-platform tags for Windows workloads? If not, what's the best practice? I'm wondering if we should remove these Windows entries altogether, in newer releases. It's not really worth it if they produce the wrong results.

Here's the manifest for the 6.0 tag

docker manifest inspect mcr.microsoft.com/dotnet/runtime:6.0

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1160,
         "digest": "sha256:03104a49e91e3c7e7b418f58fde632d417034f4432af5a1fb5c837be016a1072",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1160,
         "digest": "sha256:be7c3f289fd24fa6d9f951b6492f10793a168bf1ff4b8e19886bb4126d4c5967",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1160,
         "digest": "sha256:3726b2709032fafb4c9ceb088267170b4cced31dbbede601af550502fdbe04f6",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1754,
         "digest": "sha256:2562fee514f160375d5ae1eaf139d9eb3824551af6a4c0de0da90f794a299b62",
         "platform": {
            "architecture": "amd64",
            "os": "windows",
            "os.version": "10.0.17763.4010"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1754,
         "digest": "sha256:f74644d47bf733c4292bd1c2aa32de1384d65c5cf74cfc0bcc05f978b5b5348d",
         "platform": {
            "architecture": "amd64",
            "os": "windows",
            "os.version": "10.0.20348.1547"
         }
      }
   ]
}

[tfenster]

@richlander I think this behavior is probably caused by this containerd/containerd#6508 bug. So I would say the manifest approach is exactly the right one (or at least I as a user/developer would like to see them), but the implementation doesn't work as expected at the moment where you don't necessarily get the image that you expect if your pull references a manifest

[richlander]

Yup. We've seen this issue going back many years, just never filed an issue on it. Perhaps there is another on the same topic in this official repo. If not, it is about time there was.

It is a question of whether the Windows Team is focused on fixing this / advocating for it to be fixed. If not, I think including Windows images in multi-platform manifests doesn't make much sense, since it is encouraging a pattern that delivers poor results.

It is worth saying that the current multi-platform UX works well if you are building, testing, and hosting images on the Windows Server SKU. It's when you are on Windows client that the problem I'm reporting come into play. The only time I interact with Windows Server is via an Azure subscription. Otherwise, I'm interacting with container images on Windows client.

[tfenster]

Maybe @judyliu-ms, @vrapolinario or @thecloudtaylor have ideas on this?

[akarshm]

This is being discussed here.

[richlander]

I think you misunderstand. It is not being discussed at that issue. The core issue remains.

[akarshm]

This is already being discussed in the containerd section.

[richlander]

This change has been made: dotnet/dotnet-docker#4549