Container still appears in list after deleting all Tags

[htschan]

After deleting all tags of a container, it continues to appear in the containers list. When clicking it in the list of containers an error "404 page not found" is thrown.

If a container has no tags, then it probably should not appear in the containers list.
A container without tags doesn't occupy space after the garbage collector has run.

[parabuzzle]

this seems like a UI bug. If you go to the base url that crane operator is running on and hard refresh there, does the container no longer show up?

[vamoros96]

I have the same issue, and doing what you said doesn't solve the problem, could you check it please? I'm using docker distribution v2.6.2

[parabuzzle]

I've narrowed this down to a problem with the way an image is represented on the docker registry api. If you remove all tags it still appears in the _catalog call until garbage collection is run. In order to fix this I have two options:

1. I can check for tags on every image returned in the _catalog call which would result in an N+1 problem which would slow down the UI loading (the more images.. the slower it gets)

2. I can handle clicking on an image with no tags much more gracefully and display a message that states there are no tags associated with the selected image.

I'm much more inclined to do number 2 here and add an FAQ explaining the garbage collector process.

[natecowen]

Manually running garbage collection doesn't seem to fix this issue.

[wtigotw]

Yeah the Docker Registry seems to maintain repositories in the catalog even if there are no tags associated with them any longer (docker-archive/docker-registry#1108). Garbage collection doesn't help either. However, since it really is a Registry issue that will hopefully be addressed at some point, I agree that it would be best to simply handle it more gracefully. If I have some time next week I'll try to put a PR together.

By the way @parabuzzle thanks for building this. I've experimented with so many other registry managers and this is the only one I could get to work easily and reliably. Clean, simple, and does exactly what I want with a registry manager!

[adabuleanu]

two years later and the error still persists. any updates?

[thomasd3]

and one more year later and the error still persists. any updates? :D :D

[packetgeek]

It's a bit of a kludge but I've worked out the following. That said, the following could probably use some refinement.

Discussion

As others have stated, the issue is part of the registry container's feature set (i.e., it's external to craneoperator). The idea is that the registry container is a private registry, in which various versions of your image is stored. Short version: you can easily delete tagged versions of an image but it requires manual intervention to remove something from the catalog. Below are a couple scripts that assist with that intervention.

If you delete an image by clicking on the garbage can under the title, in the "Information" column (in the craneoperator interface), there's still some cleanup to perform in the registry container. Following scripts are executed outside of the containers and assume that the registry container is named "registry-srv". The garbage-collection could be automated but, since I'm the only user of the registry, I prefer to run it manually.

Script

1. Create a script called "cleanup.sh", containing the following:

#!/bin/bash
docker exec -t registry-srv /bin/bash -c '/bin/registry garbage-collect /etc/docker/registry/config.yml -m'

Make the above executable and run it. This will delete the blobs associated with the registry that you just deleted.

Update

I had a simple script to remove the folder in the registry but ran into a number of use cases where it would create problems. There's a difference between how the registry stores the "hello-world" image and the "rancher/rancher:v2.6.5" image. The registry creates a rancher folder AND a rancher sub-folder within that. This means that any script to remove the intended folder/sub-folder pair, without deleting folder/some-other-sub-folder, will be a bit more complicated than my original 3-line script.

Short version: it's much, much simpler to just delete the folder (or sub-folder) manually. I'm putting "scripting of folder removal" on my to-do list. It's a low priority though.

Just remember that you'll need to restart the registry container after deleting the folder, to force the reloading of the image listings.