+++ This bug was initially created as a clone of Bug #1931979 +++

Description of problem:

In various situations, glance will leak (potentially very large) temporary files in the staging store.

One example is doing a web-download import, where glance initially downloads the image to its staging store. If the worker doing that activity crashes, loses power, etc, the user may delete the image and try again on another worker. When the crashed worker resumes, the staging data will remain but nothing will ever clean it up.

Another example would be a misconfigured glance that uses local staging directories, but glance-direct is used, where the user stages data, and then deletes the image from another worker.

Even in a situation where shared staging is properly configured, a failure to access the staging location during the delete call will result in the image being deleted, but the staging file not being purged.

IMHO, glance workers should clean their staging directories at startup, purging any data that is attributable to a previous image having been deleted.

Another option is to add a store location for each staged image, and make sure the scrubber can clean those things from the staging directory periodically (this requires also running the scrubber on each node, which may not be common practice currently).

Note:
We can also backport it to previous version i.e. OSP 16

— Additional comment from Cyril Roelandt on 2021-03-04 20:22:35 UTC —

OK, once it's merged upstream, I'll look into backporting this to 16.2 and 16.1.