[additionalimagestores] Rename image ls 'R/O' column and show store path

[srcshelton]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Right now, when additionalimagestores is set and any image exists in one of the defined additional stores, the output of podman image ls gains a R/O column:

$ podman image ls
REPOSITORY                             TAG        IMAGE ID      CREATED         SIZE     R/O
localhost/gentoo-build-root            latest     c2c952975d5e  26 seconds ago  680 MB   true
localhost/gentoo-base                  latest     3796c18e4e0b  32 hours ago    1.56 GB  false
localhost/service.net-dns.bind         9.16.12    1abeea31ed8d  2 days ago      351 MB   false

However, these additional images aren't actually read-only (although they do need additional command-line options to access) and there is no indication of which store the additional images have been discovered in - simply that they exist.

My suggestion is to rename R/O to STORE, and change the value from a simple boolean to main (or graphRoot, or the graphRoot path?) or the path of the defined additional imagestore in which the image exists, e.g.:

$ podman image ls
REPOSITORY                             TAG        IMAGE ID      CREATED         SIZE     STORE
localhost/gentoo-build-root            latest     c2c952975d5e  26 seconds ago  680 MB   main
localhost/gentoo-base                  latest     3796c18e4e0b  32 hours ago    1.56 GB  /storage/images
localhost/service.net-dns.bind         9.16.12    1abeea31ed8d  2 days ago      351 MB   /storage/build

For context see #9852.

[rhatdan]

I am fine with adding the additional field, but adding a path will make the display difficult. I usually use /var/lib/shared. I still believe we should treat the additional store as read/only for the point of view of the current store. If the user wants to modify the additional store, they will need to make it primary.

[srcshelton]

Displaying a path is difficult due to the potential length or formatting issues, or because the store location isn't readily available to the code rendering the output?

Is there any link back to the storage location of the image? If the path is inaccessible, then if possible even a counter:

$ podman image ls
REPOSITORY                             TAG        IMAGE ID      CREATED         SIZE     STORE
localhost/gentoo-build-root            latest     c2c952975d5e  26 seconds ago  680 MB   1
localhost/gentoo-base                  latest     3796c18e4e0b  32 hours ago    1.56 GB  2
localhost/service.net-dns.bind         9.16.12    1abeea31ed8d  2 days ago      351 MB   2
localhost/service.net-im.bitlbee       3.6-r1     51436d6982b3  3 weeks ago     101 MB   3

… would at least give some indication of where the image is (although without a means to get a store location to number mapping, it's not a huge improvement…)

Consider the use-case:

• I have several [additionalimagestores] defined;
• I have an image I wish to remove;
• Unless [additionalimagestores] Allow prune to operate on additional stores #10392 and/or [additionalimagestores] Allow global operations across all defined image stores #10394 are implemented, I need to specify the exact store I want to operate on;
• Without this update, I don't know where the image is located, because image ls will only tell me whether it's here or elsewhere!

… so there may be a cleverer solution, but without this enhancement is looks to me as if the only option is to loop over every image store with the --root option until one is found where the image is listed in the primary store?!

[rhatdan]

I think it would be best to leak the information in containers/storage into the image struct. Then you would have access to it in podman.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[baude]

@vrothberg wdyt here? is this something we can efficiently do in our image lib?

[baude]

could we just consider putting image stores in something like podman info ? less costly?

[rhatdan]

That would not solve the issue of where does this specific image come from.

I will take a look at this.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

podman info
...
    overlay.imagestore: /var/lib/shared

Now displays the image store. Not sure if we can do much better.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[vrothberg]

@vrothberg wdyt here? is this something we can efficiently do in our image lib?

Apologies for missing the ping. Yes, I am sure we can assemble the storage path in libimage.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Since podman info will show the additional store, I think that is good enough.