image ls: show each tag for an image as a separate entry #5556
Conversation
thaJeztah
added
kind/enhancement
status/2-code-review
area/ux
containerd-integration
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5556 +/- ##
==========================================
- Coverage 59.57% 59.54% -0.04%
==========================================
Files 345 345
Lines 29088 29105 +17
==========================================
Hits 17330 17330
- Misses 10788 10805 +17
Partials 970 970 |
A single image can be tagged under multiple names. While they are the
same image under the hood (same digest), we always presented these as
separate images in the list.
This patch applies the same behavior for the tree view; we can consider
having some "compact" presentation in future where we collapse these iamges
(perhaps introducing a "names" column?)
Before this patch:
$ docker pull --quiet alpine:3.20
docker.io/library/alpine:3.20
$ docker pull --quiet alpine:latest
docker.io/library/alpine:latest
$ docker image ls --tree
IMAGE ID DISK USAGE CONTENT SIZE USED
alpine:3.20
alpine:latest beefdbd8a1da 13.6MB 4.09MB
├─ linux/arm64/v8 9cee2b382fe2 13.6MB 4.09MB
├─ linux/amd64 33735bd63cf8 0B 0B
├─ linux/arm/v6 50f635c8b04d 0B 0B
├─ linux/arm/v7 f2f82d424957 0B 0B
├─ linux/386 b3e87f642f5c 0B 0B
├─ linux/ppc64le c7a6800e3dc5 0B 0B
├─ linux/riscv64 80cde017a105 0B 0B
└─ linux/s390x 2b5b26e09ca2 0B 0B
With this patch applied:
$ docker image ls --tree
IMAGE ID DISK USAGE CONTENT SIZE USED
alpine:3.20 beefdbd8a1da 13.6MB 4.09MB
├─ linux/arm64/v8 9cee2b382fe2 13.6MB 4.09MB
├─ linux/amd64 33735bd63cf8 0B 0B
├─ linux/arm/v6 50f635c8b04d 0B 0B
├─ linux/arm/v7 f2f82d424957 0B 0B
├─ linux/386 b3e87f642f5c 0B 0B
├─ linux/ppc64le c7a6800e3dc5 0B 0B
├─ linux/riscv64 80cde017a105 0B 0B
└─ linux/s390x 2b5b26e09ca2 0B 0B
alpine:latest beefdbd8a1da 13.6MB 4.09MB
├─ linux/arm64/v8 9cee2b382fe2 13.6MB 4.09MB
├─ linux/amd64 33735bd63cf8 0B 0B
├─ linux/arm/v6 50f635c8b04d 0B 0B
├─ linux/arm/v7 f2f82d424957 0B 0B
├─ linux/386 b3e87f642f5c 0B 0B
├─ linux/ppc64le c7a6800e3dc5 0B 0B
├─ linux/riscv64 80cde017a105 0B 0B
└─ linux/s390x 2b5b26e09ca2 0B 0B
Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah
force-pushed
the
tree_ungroup
branch
from
3b2eef0
to
7187c78
Compare
There was a problem hiding this comment.
I don't see any benefit to showing them as a separate entities:
- It duplicates a lot of information
- There are no separate content for each of the images. The underlying content is the same and there's no way to modify the image without either creating a new content or mutating other images with the same target.
The reason we always presented these as separate images in the list is also not convincing 🙈
|
Hmmm.. yeah, not sure I agree; yes, it's more verbose (and yes, content is duplicated). I think for most intents and purposes users would consider them separate things. You need to pull them separately (which may be from different registries), delete them separately, and push them separately. It can be useful to know that some images may have names (or tags) that point to the same digest but, somewhat similar to tags on a Git repository, where (as a user) I would look at the tag / version, before considering if they could be pointing to the same commit. The image name often has a meaningful purpose; both to find the image when browsing the list (which could be relevant to, e.g. "remove that temporary image name"), but also, for example, Docker Content Trust, which signs images by name (so signing may apply to one name, but not the other). We also don't do the same for the platform variants underneath, those variants could be referenced in multiple images (not always in the same combination), or it could be that I have a single-platform image that is also contained as a variant in a multi-platform one. All that said 👉 we should look if could somehow indicate that they're identical to another image (perhaps also from a perspective of size/usage being "shared" or not). If we do consider them "same image", we should flip to use ID in the list, and tag(s) as secondary But no idea how to present the The tricky bit with "grouping" them is that if we would decide to show images alphabetically, what should we show? |
|
Wrote down a somewhat alternative on #5560 (comment) |
--treeflag #4982docker image ls --treefor images with multiple names/tags #5555A single image can be tagged under multiple names. While they are the same image under the hood (same digest), we always presented these as separate images in the list.
This patch applies the same behavior for the tree view; we can consider having some "compact" presentation in future where we collapse these iamges (perhaps introducing a "names" column?)
Before this patch:
With this patch applied:
- What I did
- How I did it
- How to verify it
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)