Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1945634

Summary: Glance will leak staging data
Product: Red Hat OpenStack Reporter: Abhishek Kekane <akekane>
Component: openstack-glanceAssignee: Cyril Roelandt <cyril>
Status: CLOSED MIGRATED QA Contact: msava
Severity: medium Docs Contact: RHOS Documentation Team <rhos-docs>
Priority: high    
Version: 16.2 (Train)CC: athomas, cyril, dasmith, eglynn, gcharot, msava, udesale
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1931979 Environment:
Last Closed: 2025-01-22 16:17:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1931979    
Bug Blocks:    

Description Abhishek Kekane 2021-04-01 13:35:51 UTC 
+++ 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.