nerdctl images displays the wrong image id

[apostasie]

Description

Whenever nerdctl displays lists of images (nerdctl images, nerdctl image list), the ID being reported are the repo sha, not the image ID.

Compare with Docker.

Steps to reproduce the issue

1. nerdctl images
2. docker images

Describe the results you received and expected

Expected: Docker behavior - see the image ID.

Received: repo digest

What version of nerdctl are you using?

1.7.6

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

None

Host information

No response

[AkihiroSuda]

The image IDs are different from Docker

nerdctl/cmd/nerdctl/image_list.go

Line 37 in cefa8ce

- IMAGE ID: OCI Digest. Usually different from Docker image ID. Shared for multi-platform images.

[apostasie]

I see.

Was there a reason for that choice?

The problems I see:

• it does make nerdctl and docker fundamentally disagree on what defines the "same image".

• it will also lead to internal inconsistent behavior with nerdctl wrt to commands like rmi.

Specifically:

sudo nerdctl pull debian >/dev/null 2>&1
sudo nerdctl tag debian apostasie/nerdctl-test
sudo nerdctl push apostasie/nerdctl-test

shortid="$(sudo nerdctl inspect apostasie/nerdctl-test | jq -rc .[0].RepoDigests[0])"
shortid="${shortid##*:}"
shortid="${shortid:0:8}"

sudo nerdctl rmi -f "$shortid"

sudo nerdctl images # <- empty

# Now...

sudo nerdctl pull debian  >/dev/null 2>&1
sudo nerdctl pull apostasie/nerdctl-test  >/dev/null 2>&1

shortid="$(sudo nerdctl inspect apostasie/nerdctl-test | jq -rc .[0].RepoDigests[0])"
shortid="${shortid##*:}"
shortid="${shortid:0:8}"

sudo nerdctl rmi -f "$shortid"

sudo nerdctl images # <- not empty

This is obviously due to the fact that the RepoDigest will be different for the very same image depending on whether it has been pushed&pulled or not.

I can maybe fix it, by querying and keying images during lookup along the "docker" Id, but it is going to make things more complicated and possibly lead to some other types of discrepancies.

[AkihiroSuda]

containerd's image store is designed to use a single object for multi-platform image index, while Docker's image store is designed to allocate an object per platform.

[AkihiroSuda]

BTW nerdctl image inspect has been using Docker-compatible ID which is incompatible with the ID shown in nerdctl images:

nerdctl/pkg/inspecttypes/dockercompat/dockercompat.go

Line 331 in 3ca6e8b

i.ID = n.ImageConfigDesc.Digest.String() // Docker ID (digest of platform-specific config), not containerd ID (digest of multi-platform index or manifest)

This behavior looks inconsistent and needs some remedy...

[AkihiroSuda]

Relevant:

• WIP: containerd integration: Multi-platform images UX moby/moby#47680
• c8d: Multi-platform image list moby/moby#47526

nerdctl's output should be consistent with moby/moby#47526 (when the PR gets merged)

[apostasie]

Agreed.

Overall, all of it does not look good.
I strongly believe we cannot use repodigest hash as a way to define what an image is - this is just wrong and will lead to many issues (among which the fact that an image will "change" after push according to nerdctl).

I will have a look at the Moby PR and see what we can do here.

[apostasie]

BTW nerdctl image inspect has been using Docker-compatible ID which is incompatible with the ID shown in nerdctl images:

nerdctl/pkg/inspecttypes/dockercompat/dockercompat.go

Line 331 in 3ca6e8b

i.ID = n.ImageConfigDesc.Digest.String() // Docker ID (digest of platform-specific config), not containerd ID (digest of multi-platform index or manifest)

This behavior looks inconsistent and needs some remedy...

Well... image list will definitely show the repo sha in the ID column (and not the Docker ID).

And image inspect does NOT allow querying by Docker id.

My "inspect" PR also respected that so far.

We might need a design discussion here.

[apostasie]

containerd's image store is designed to use a single object for multi-platform image index, while Docker's image store is designed to allocate an object per platform.

The store is one thing, what we conceptually present to the user is another.

The core issue here is: what we currently show to the user is inconsistent, and breaks reproducibility and some of our commands in certain conditions.