If delayed_delete is enabled in Glance, deleting an image changes its status to pending_delete. Later, a scheduled scrubber permanently deletes these images, updating their status to deleted in the database. Since Glance’s unified limits only consider images in the killed and deleted states, this can lead to inaccurate usage reporting and improper enforcement of limits, potentially blocking users unfairly.

For example:

$ glance image-list
+----+------+
| ID | Name |
+----+------+
+----+------+

This indicates that the user currently has no active images, so the usage limit should be zero. However, the actual reported usage might still show non-zero values, which is misleading.

$ glance usage
+-----------------------+-------+--------+
| Quota                 | Limit | Usage  |
+-----------------------+-------+--------+
| image_size_total      | 1000  | 942366 |
| image_stage_total     | 1000  | 0      |
| image_count_total     | 100   | 108    |
| image_count_uploading | 100   | 0      |
+-----------------------+-------+--------+

In this example, there are 108 images in the pending_delete state. Since the usage report does not consider images in pending_delete, it overstates the actual resource usage. Additionally, if unified limits are disabled, the specified limits (e.g., 100 for image_count_total and 1000 for image_size_total) are not enforced properly.

The expected behavior is that, if the user has no active images, all usage metrics should display as zero.

Expected output should be;

$ glance usage
+-----------------------+-------+-------+
| Quota                 | Limit | Usage |
+-----------------------+-------+-------+
| image_size_total      | 1000  | 0     |
| image_stage_total     | 1000  | 0     |
| image_count_total     | 100   | 0     |
| image_count_uploading | 100   | 0     |
+-----------------------+-------+-------+