Podman: RFE: allow an image to be untagged

[dustymabe]

From https://github.com/containers/libpod/issues/387#issue-299492901: "Podman does not do this, and AFAICT does not offer a way to remove a tag"

I think this is still the case today. I can't figure out how to untag an image without removing the image layers. The use case for this is narrow, but seems like the functionality should exist in the form of podman image untag TAG or podman image tag --untag TAG.

Right now the workaround if you want to drop a tag but keep the image layers is to:

$ sudo podman image tag 6c1065ada252 foo
$ sudo podman rmi localhost/simple-kmod-557e851:5.3.7-300.fc31.x86_64
Untagged: localhost/simple-kmod-557e851:5.3.7-300.fc31.x86_64

Version: podman-1.6.1-2.fc31.x86_64

[rhatdan]

Something like
podman image rmtag IMAGE[:TAG] IMAGE[:TAG]

[rhatdan]

Does Docker do this now? I thought podman will remove the image if their is only one "name".
If you do

podman pull fedora:31
podman tag fedora:31 mytag
podman rmi mytag

Isn't fedora:31 still installed?

[dustymabe]

Does Docker do this now?

I don't think so.

I thought podman will remove the image if their is only one "name".
If you do

podman pull fedora:31
podman tag fedora:31 mytag
podman rmi mytag

Isn't fedora:31 still installed?

Yes. My workaround I mentioned shows this because it just untags and does not remove any layers. In my case I wanted to remove just the tag but wanted to keep the layers because I knew they'd be useful as cached layers for future operations. Seems like a simple operation that currently can't be done.

[rhatdan]

The images need at least one name to reference them, which is why it removes the blobs when their are no more names.

[rhatdan]

@nalind @mtrmac WDYT?

[mtrmac]

*shrug* without reading all of the code, adding support for just removing the tags sounds like something that should be rather easy. Perhaps teaching podman rmi -a to deal with untagged images, if it doesn’t do so already, might be the bigger part of the work.

I’m _much_ more worried about the expectation that untagged images can then be practically managed, though. c/image/storage _does_ support image ID references, so all of this _could_ work — but consider whether all the “what does this string mean” heuristics throughout the podman stack can deal with such inputs consistently — and ultimately, whether _that_ detailed review is worth the effort. (It is _possible_ that it actually works well enough already, but at least I can’t find any tests exercising that, and the complexity and roundaboutness of the various heuristics makes me really doubt that.) Yet again, this RFE might be a good enough reason for someone to actually nail down the string semantics and pare down the heuristics to clearly, unambiguously and exactly that.

In my case I wanted to remove just the tag but wanted to keep the layers because I knew they'd be useful as cached layers for future operations.

• If it is known what _images_ will be used, it would seem natural to just pull them and keep the tags.
• Builds that pull a big image and add a tiny layer on top would benefit, even more, from caching the original compressed blob artifacts, and IIRC that can actually be set up (in some cases)?
• … which leaves, I guess, a big set of images built as fairly small layers on top of a shared base image, and it is known that _some_ image like that will be used but not _which_ one, so pulling the shared base image in advance can be a a legitimate optimization… OTOH I’m not sure that pulling the shared base image by digest and keeping the digest tag around hurts enough to be worth the effort.
• Any other case I’m missing?

[dustymabe]

shrug without reading all of the code, adding support for just removing the tags sounds like something that should be rather easy.

I would think so :)

Perhaps teaching podman rmi -a to deal with untagged images, if it doesn’t do so already, might be the bigger part of the work.

podman image prune does this already today IIUC. Basically find any dangling images and remove them.

I’m _much_ more worried about the expectation that untagged images can then be practically managed, though.

I really don't understand the complexity here, but I could be mistaken in my understanding. If I podman build -t foo . today, then change the Dockerfile then podman build -t foo again won't the localhost/foo:latest tag get overwritten and there will be dangling images that are left behind? IOW the images don't get cleaned up by default. I've provided an example below:

[vagrant@vanilla-f31 ~]$ cat Dockerfile 
FROM fedora:30
ARG FIRSTARG
RUN echo ${FIRSTARG} > /root/firstarg
ARG SECONDARG
RUN echo ${SECONDARG} > /root/secondarg
[vagrant@vanilla-f31 ~]$ 
[vagrant@vanilla-f31 ~]$ podman images -a
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE
[vagrant@vanilla-f31 ~]$ 
[vagrant@vanilla-f31 ~]$ podman build -t example --build-arg FIRSTARG=a --build-arg SECONDARG=b .
STEP 1: FROM fedora:30
Getting image source signatures
Copying blob 9908e4690737 done
Copying config 9eff96f4c8 done
Writing manifest to image destination
Storing signatures
STEP 2: ARG FIRSTARG
1bc8295a0c1cd0180e14f5f1fbea3faedb9fc673073cc090b3020167a1c47d2d
STEP 3: RUN echo ${FIRSTARG} > /root/firstarg
7eac103ec05a4f0ffdfa3c939de470523fbf4606902e934a393093b0c8b9fbc7
STEP 4: ARG SECONDARG
56db6c4de65844f38e5c80ee5bd926377ff7eda3614682984ce3f9dead6ed904
STEP 5: RUN echo ${SECONDARG} > /root/secondarg
STEP 6: COMMIT example
b78040445d7b07203939592396f3c31cfc8ea0b374e39c2268c8dde8f6df4ea0
[vagrant@vanilla-f31 ~]$ 
[vagrant@vanilla-f31 ~]$ podman build -t example --build-arg FIRSTARG=a --build-arg SECONDARG=c .
STEP 1: FROM fedora:30
STEP 2: ARG FIRSTARG
--> Using cache 1bc8295a0c1cd0180e14f5f1fbea3faedb9fc673073cc090b3020167a1c47d2d
STEP 3: RUN echo ${FIRSTARG} > /root/firstarg
21b579be35710ef1c84d9737ce5494b26a6cb68d374be4dd39436b76d6dd68da
STEP 4: ARG SECONDARG
e6970b2ad554d3e756eecea240da76d45d4bf87323809ce884684089514284b3
STEP 5: RUN echo ${SECONDARG} > /root/secondarg
STEP 6: COMMIT example
f92941eb8d9753911c104acd368761b42c10d842900bd234cc59594312a6de00
[vagrant@vanilla-f31 ~]$ 
[vagrant@vanilla-f31 ~]$ 
[vagrant@vanilla-f31 ~]$ podman images -a
REPOSITORY                 TAG      IMAGE ID       CREATED          SIZE
localhost/example          latest   f92941eb8d97   6 seconds ago    256 MB
<none>                     <none>   e6970b2ad554   7 seconds ago    256 MB
<none>                     <none>   21b579be3571   10 seconds ago   256 MB
<none>                     <none>   b78040445d7b   20 seconds ago   256 MB
<none>                     <none>   56db6c4de658   21 seconds ago   256 MB
<none>                     <none>   7eac103ec05a   24 seconds ago   256 MB
<none>                     <none>   1bc8295a0c1c   25 seconds ago   256 MB
docker.io/library/fedora   30       9eff96f4c827   3 weeks ago      256 MB

In my case I wanted to remove just the tag but wanted to keep the layers because I knew they'd be useful as cached layers for future operations.

* If it is known what _images_ will be used, it would seem natural to just pull them and keep the tags.

In my case it was all local builds. What i was doing was testing a framework that queues off the existence of an image to determine if it is going to do a new build. If the image (with a specific tag) doesn't exists it does a new build. What I was trying to do was remove the image tag and then do a new build (but allowing for all caches to be re-used, to streamline the process). So I simply needed to untag an image without removing the layers. I thought it was such a simple thing that it seemed odd it couldn't be done without a workaround, which is why I opened the request.

[mtrmac]

I’m _much_ more worried about the expectation that untagged images can then be practically managed, though.

I really don't understand the complexity here, but I could be mistaken in my understanding. If I podman build -t foo . today, then change the Dockerfile then podman build -t foo again won't the localhost/foo:latest tag get overwritten and there will be dangling images that are left behind?

Right.

[vagrant@vanilla-f31 ~]$ podman images -a
REPOSITORY                 TAG      IMAGE ID       CREATED          SIZE
localhost/example          latest   f92941eb8d97   6 seconds ago    256 MB
<none>                     <none>   e6970b2ad554   7 seconds ago    256 MB
<none>                     <none>   21b579be3571   10 seconds ago   256 MB

The complexity I’m worried about is naming the dangling images. It is supposed to be possible to refer to them using @e6970b2ad554, or maybe e6970b2ad554, or maybe only the full long versions of the image IDs, or maybe in some cases sha256:e6970b2ad554 works (sha256:@e6970b2ad554 even?), and most likely it depends on the exact code path. It’s not that the _concept_ is difficult, I’m worried about the twisty passages in the current code that resolves strings into image objects to try and do the right thing, exactly what the user expects.

[dustymabe]

The complexity I’m worried about is naming the dangling images. It is supposed to be possible to refer to them using @e6970b2ad554, or maybe e6970b2ad554, or maybe only the full long versions of the image IDs, or maybe in some cases sha256:e6970b2ad554 works (sha256:@e6970b2ad554 even?), and most likely it depends on the exact code path. It’s not that the _concept_ is difficult, I’m worried about the twisty passages in the current code that resolves strings into image objects to try and do the right thing, exactly what the user expects.

Can users refer to image by ID today? If yes, then the possible bugs that you mention already exist and should probably be fixed. This RFE would possibly bring those bugs to light faster.

IIUC this feature wouldn't cause any regressions, but would help us find bugs that already exist.

[dustymabe]

IIUC this feature wouldn't cause any regressions, but would help us find bugs that already exist.

or maybe you're referring to internal naming and not external naming that the user provides?

[mtrmac]

Can users refer to image by ID today? If yes, then the possible bugs that you mention already exist and should probably be fixed.

Sure. It’s just these, until now obscure, corner cases would become noticeably more important.

[github-actions[bot]]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

I think we could still do this fairly easily and I don't see any issues with doing it. So I will leave this open.

[github-actions[bot]]

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

[rhatdan]

@saschagrunert @dustymabe Does https://github.com/containers/libpod/pull/4712 close this?

[saschagrunert]

From my point of view yes, but I leave it open to @dustymabe :)

[dustymabe]

Looks like that would satisfy the feature request, yes. I'll test when it filters into a release and comment here if it's not working as expected.

[dustymabe]

Thanks @saschagrunert @rhatdan