Buildah rmi untagged/removed the wrong image/manifest-list

[cevich]

Description

When removing (untagging) a specific manifest-list, it's arguably intuitive to expect only the named item to be removed. That's not what's happening as of 4d22922

Steps to reproduce the issue:

1. podman system reset --force
2. make bin/buildah
3. bin/buildah pull alpine
4. bin/buildah manifest create foobar
5. bin/buildah manifest add foobar alpine
6. bin/buildah tag foobar foobar2
7. bin/buildah rmi foobar2

Describe the results you received:

~/dev/buildah ((4d229222…)|✔) $ podman system reset --force
~/dev/buildah ((4d229222…)|✔) $ bin/buildah pull alpine
Resolved "alpine" as an alias (/home/cevich/.cache/containers/short-name-aliases.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob a0d0a0d46f8b done
Copying config 14119a10ab done
Writing manifest to image destination
Storing signatures
14119a10abf4669e8cdbdff324a9f9605d99697215a0d21c360fe8dfa8471bab
~/dev/buildah ((4d229222…)|✔) $ bin/buildah manifest create foobar
8dabe4488c88099414a7f9aa20edc40f29f05da0fc25e2d756e352a54a55f247
~/dev/buildah ((4d229222…)|✔) $ bin/buildah manifest add foobar alpine
8dabe4488c88099414a7f9aa20edc40f29f05da0fc25e2d756e352a54a55f247: sha256:69704ef328d05a9f806b6b8502915e6a0a4faa4d72018dc42343f511490daf8a
~/dev/buildah ((4d229222…)|✔) $ bin/buildah tag foobar foobar2
~/dev/buildah ((4d229222…)|✔) $ bin/buildah rmi foobar2
untagged: docker.io/library/alpine:latest
14119a10abf4669e8cdbdff324a9f9605d99697215a0d21c360fe8dfa8471bab

Describe the results you expected:

Only the foobar2 manifest list should have been removed.

Output of rpm -q buildah or apt list buildah:

buildah compiled from 4d22922

Output of buildah version:

Version:         1.23.0-dev
Go Version:      go1.15.14
Image Spec:      1.0.1-dev
Runtime Spec:    1.0.2-dev
CNI Spec:        0.4.0
libcni Version:  v0.8.1
image Version:   5.16.0
Git Commit:      4d229222
Built:           Mon Aug 30 15:55:05 2021
OS/Arch:         linux/amd64
BuildPlatform:   linux/amd64

Output of podman version if reporting a podman build issue:

N/A

Output of cat /etc/*release:

Fedora release 33 (Thirty Three)
NAME=Fedora
VERSION="33 (Workstation Edition)"
ID=fedora
VERSION_ID=33
VERSION_CODENAME=""
PLATFORM_ID="platform:f33"
PRETTY_NAME="Fedora 33 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:33"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=33
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=33
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation
Fedora release 33 (Thirty Three)
Fedora release 33 (Thirty Three)

Output of uname -a:

Linux localhost.localdomain 5.13.12-100.fc33.x86_64 #1 SMP Wed Aug 18 20:12:01 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

unmodified from install of containers-common-1-20.fc33.noarch

[cevich]

@nalind PTAL, this seems to me a particularly bad problem (surprising to users) 😕 I double-checked and it does reproduce under F34 using a get_ci_vm.sh VM (so it's not just my janky F33 laptop) 😢

[nalind]

This sounds like it's of a piece with #3467. @flouthoc, I think you mentioned you were doing follow-up work for #3483 earlier. If I remembered that correctly, is this that?

[cevich]

Yes, I found this right after running tests against script I'm working on. I was specifically verifying the new tag support would pass all my checks, but other commits came in as well, so I didn't want to assume.

[flouthoc]

@nalind Yes this is the correct issue , same issue persists with podman and has been reported with upstream. I'll take care for both of them containers/podman#11344

[flouthoc]

@cevich buildah rmi is doing the correct job since rmi is for remove-images it doesn't really cares if image is coming from manifest list and works as expected as per man-pages, unlike tag since images is explicitly mentioned here i think this is doing the correct job.

You should use buildah manifest rm however it has a similar bug which is fixed in #3492

[cevich]

You should use buildah manifest rm

Oh okay that makes sense (and thanks for taking care of the manifest rm problem). I think many users will intuitively reach for buildah rmi though, so maybe I can help by improving the documentation. Conveniently it already has a 'Limitations' section 😁

[flouthoc]

@cevich I'll fix the documentation as well as soon as the manifest rm fix is in. 😄

[cevich]

Oh no worries, I can help there, focus on the code 😁