All database API's currently include deleted images in the calc of
storage usage. This is not an issue when deleted images don't have
locations. However, there are cases where a deleted image has deleted
locations as well and that causes the current algorithm to count those
locations as if they were allocating space.
Besides this bug, it makes sense to not load deleted / killed /
pending_delete images from the database if we're actually not
considering them as valid images.
The patch also filters out deleted locations.
NOTE: In the case of locations, it was not possible to add a test for
the deleted locations because it requires some changes that are not
worth in this patch. In order to mark a location as deleted, it's
necessary to go through the API and use a PATCH operation. Since this is
a database test, it doesn't make much sense to add API calls to it.
Calling the image_destroy function with an empty location list will
remove all the locations which won't help testing that specific case.
I'll work on a better solution for that in a follow-up patch.
DocImpact:
The patch now excludes deleted images from the count, this fixes a
bug but changes the existing behaviour.
The patch excludes images in pending_delete from the count, although
the space hasn't be freed yet. This may cause the quota to be
exceeded without raising an error until the image is finally deleted
from the store.
Reviewed: https:/ /review. openstack. org/63455 /git.openstack. org/cgit/ openstack/ glance/ commit/ ?id=4e26df9c922 d96473fdd27782a f0fed93f0a79de
Committed: https:/
Submitter: Jenkins
Branch: stable/havana
commit 4e26df9c922d964 73fdd27782af0fe d93f0a79de
Author: Flavio Percoco <email address hidden>
Date: Wed Dec 18 15:18:17 2013 +0100
Filter out deleted images from storage usage
All database API's currently include deleted images in the calc of
storage usage. This is not an issue when deleted images don't have
locations. However, there are cases where a deleted image has deleted
locations as well and that causes the current algorithm to count those
locations as if they were allocating space.
Besides this bug, it makes sense to not load deleted / killed /
pending_delete images from the database if we're actually not
considering them as valid images.
The patch also filters out deleted locations.
NOTE: In the case of locations, it was not possible to add a test for
the deleted locations because it requires some changes that are not
worth in this patch. In order to mark a location as deleted, it's
necessary to go through the API and use a PATCH operation. Since this is
a database test, it doesn't make much sense to add API calls to it.
Calling the image_destroy function with an empty location list will
remove all the locations which won't help testing that specific case.
I'll work on a better solution for that in a follow-up patch.
DocImpact:
The patch now excludes deleted images from the count, this fixes a
bug but changes the existing behaviour.
The patch excludes images in pending_delete from the count, although
the space hasn't be freed yet. This may cause the quota to be
exceeded without raising an error until the image is finally deleted
from the store.
Conflicts: tests/functiona l/db/test_ sqlalchemy. py
glance/
Closes-Bug: #1261738 c213eed7bc35a1f 062c99dcca) 541e4f77597c2ba 0aeb68556ce
(cherry picked from commit b35728019e0eb89
Change-Id: I82f08a8f522c81