c8d: Adjust "image list" to return only a single item for each image store entry

[tianon]

This will return a single entry for each name/value pair, and for now all the "image specific" metadata (labels, config, size) should be either "default platform" or "first platform we have locally" (which then matches the logic for commands like docker image inspect, etc) with everything else (just ID, maybe?) coming from the manifest list/index. That leaves room for the longer-term implementation to add new fields to describe the other images that are part of the manifest list/index.

Refs #45948, #45735 (especially #45735 (comment))

[rumpl]

I don't think we should merge this, the current API response might not be backwards compatible for some clients (it is for the docker cli), but at least it gives information about all the images that are pulled/built. This change would hide that information. I think we should hold on while we get the final shape of the multi-platform aware API and a new version of the cli that knows how to show all the information about all the local images.

[thaJeztah]

I do think that the current situation is confusing, and that this PR brings us one step closer to the intended outcome;

docker pull busybox:latest
1fa89c01cd04: Already exists
fc9db2894f4e: Already exists
3fbc63216742: Already exists
docker.io/library/busybox:latest

docker image ls
REPOSITORY         TAG               IMAGE ID       CREATED         SIZE
busybox            latest            3fbc63216742   5 seconds ago   6.09MB

docker image inspect --format '{{.Architecture}}' 3fbc63216742
arm64

docker image inspect --format '{{.Size}}' 3fbc63216742
1920927

docker pull --platform=linux/amd64 busybox:latest
3fbc63216742: Already exists
023917ec6a88: Download complete
a416a98b71e2: Download complete
3f4d90098f5b: Download complete
docker.io/library/busybox:latest

docker image ls
REPOSITORY         TAG               IMAGE ID       CREATED         SIZE
busybox            latest            3fbc63216742   5 seconds ago   6.09MB
busybox            latest            3fbc63216742   9 days ago      6.61MB

docker image inspect --format '{{.Architecture}}' 3fbc63216742
arm64

docker image inspect --format '{{.Size}}' 3fbc63216742
1920927

Even though there's 2 images shown, there's no way to interact with them individually; removing busybox:latest will remove both, and so does removing an image by "ID".

It currently also breaks Desktop's Dashboard; here's the overview of images (the overview does not show the right size for each):

Search for "busybox", and you now have 4 images:

Search again, and now you have 7 images:

[rumpl]

Even though there's 2 images shown, there's no way to interact with them individually

Exactly why my proposal was to temporarily show the manifest ID and not the manifest list ID. Also adding the platform to the images list would be a nice way to tell them appart

I do think that the current situation is confusing, and that this PR brings us one step closer to the intended outcome;

I agree that it's confusing currently, but I don't agree that this takes us any closer to the end goal. This change is also confusing, building a multi-platofrm image yields only one image in docker images, which is very confusing. That's why I think we should hold on and work on the final multi-platform aware API

[thaJeztah]

building a multi-platofrm image yields only one image in docker images, which is very confusing.

That's why it's a multi-platform image. If you want multiple platform images, you would give them a different name.

[vvoland]

I went ahead and rebased this, addressed some of the TODOs.

Windows failures expected.

[thaJeztah]

Ah, yes, was about to ask if we could test this. As these are minimal images, perhaps we could include them in our "frozen images"?

I'm fine with doing that in a follow-up if it's complicated though.

[vvoland]

Not sure if it makes sense to handle this right now.

1. It's impossible to pull such image, you can only load it via docker load (or going via containerd store directly).
2. Even if it is loaded, there's nothing that can be done with that image (except removing/pushing it).

[thaJeztah]

Oh! I should read properly, I thought this one also described "multi-arch" image to test. But this was only for the "lots' of emptiness" case.

I mostly meant; we should have a test to verify that multiple arches of an image are properly grouped into a single image when using docker image ls (i.e., with this PR merged)

[thaJeztah]

LGTM

[thaJeztah]

Gave this one another spin;

docker pull busybox
Using default tag: latest
latest: Pulling from library/busybox
c2bf9493c1bf: Download complete
Digest: sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74
Status: Downloaded newer image for busybox:latest
docker.io/library/busybox:latest


docker pull --platform=linux/amd64 busybox
Using default tag: latest
latest: Pulling from library/busybox
9ad63333ebc9: Download complete
Digest: sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74
Status: Image is up to date for busybox:latest
docker.io/library/busybox:latest

Before this PR:

docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
busybox      latest    6d9ac9237a84   5 weeks ago   6.61MB
busybox      latest    6d9ac9237a84   5 weeks ago   6.09MB

After this PR:

docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
busybox      latest    6d9ac9237a84   5 weeks ago   6.61MB

As a follow-up (?) we should probably look at the SIZE column; as we only have a single SIZE (but multiple images), we should consider making the SIZE the total size of those images, so that pulling additional content will show that there's more space occupied by the image.

[vvoland]

Good call, I added test and combined the image size.
It turned out to be a bit more code than I expected: #47449 🙈

Do we want to merge this as-is and then review the follow up separately?