yahoo-eng-team team mailing list archive

[Abhishek Kekane <2118756@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: glance
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/2118756

Title:
  Unified limits returns wrong usage if delayed_delete is enabled

Status in Glance:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/2118756/+subscriptions