[glance] zeroing image, preserving other parameters
Dear colleagues, for some reasons, I need to shrink image size to zero (freeing storage as well), while keeping this record in Glance database. First which come to my mind is to delete image and then create new one with same name/uuid/... and --file /dev/null, but this is impossible because Glance don't really delete records from database, marking them as 'deleted' instead. Next try was to use glance image-upload from /dev/null, but this is also prohibited with message "409 Conflict: Image status transition from [activated, deactivated] to saving is not allowed (HTTP 409)" I found https://docs.openstack.org/glance/rocky/contributor/database_architecture.html#glance-database-public-api's "image_destroy" but have no clues on how to access this API. Is it kind of library or kind of REST API, how to access it and whether it's safe to use it in terms of longevity and compatibility between versions? Or, may be, you can advise any other methods to solve the problem of zeroing glance image data / freeing storage, while keeping in database just a record about this image? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
On 6/5/19 8:34 AM, Volodymyr Litovka wrote:
Dear colleagues,
for some reasons, I need to shrink image size to zero (freeing storage as well), while keeping this record in Glance database.
First which come to my mind is to delete image and then create new one with same name/uuid/... and --file /dev/null, but this is impossible because Glance don't really delete records from database, marking them as 'deleted' instead.
The glance-manage utility program allows you to purge the database. The images table (where the image UUIDs are stored) is not purged by default because of OSSN-0075 [0]. See the glance docs [1] for details. [0] https://wiki.openstack.org/wiki/OSSN/OSSN-0075 [1] https://docs.openstack.org/glance/latest/admin/db.html#database-maintenance (That doesn't really help your issue, I just wanted to point out that there is a way to purge the database.)
Next try was to use glance image-upload from /dev/null, but this is also prohibited with message "409 Conflict: Image status transition from [activated, deactivated] to saving is not allowed (HTTP 409)"
That's correct, Glance will not allow you to replace the image data once an image has gone to 'active' status.
"image_destroy" but have no clues on how to access this API. Is it kind of library or kind of REST API, how to access it and whether it's safe to use it in terms of longevity and compatibility between versions?
The title of that document is misleading. It describes the interface that Glance developers can use when they need to interact with the database. There's no tool that exposes those operations to operators.
Or, may be, you can advise any other methods to solve the problem of zeroing glance image data / freeing storage, while keeping in database just a record about this image?
If you purged the database, you could do your proposal to recreate the image with a zero-size file -- but that would give you an image with status 'active' that an end user could try to boot an instance with. I don't think that's a good idea. Additionally, purging the images table of all UUIDs, not just the few you want to replace, exposes you to OSSN-0075. An alternative--and I'm not sure this is a good idea either--would be to deactivate the image [2]. This would preserve all the current metadata but not allow the image to be downloaded by a non-administrator. With the image not in 'active' status, nova or cinder won't try to use it to create instances or volumes. The image data would still exist, though, so you'd need to delete it manually from the backend to really clear out the space. Additionally, the image size would remain, which might be useful for record-keeping, although on the other hand, it will still count against the user_storage_quota. And the image locations will still exist even though they won't refer to any existing data any more. (Like I said, I'm not sure this is a good idea.) [2] https://developer.openstack.org/api-ref/image/v2/#deactivate-image
Thank you.
Not sure I was much help. Let's see if other operators have a good workaround or a need for this kind of functionality.
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
Hi Brian, thanks for the response. I solved my issue from other (client) side - I'm using Heat and Heat don't look whether uuid of image changed, it just check for existense of image with specified name. So it's safe to delete image and then create another one with same name and parameters and zero size. But in fact, Glance has a bit contradictory approach: Documentation on db purge says: "Remember that image identifiers are used by other OpenStack services that require access to images. These services expect that when an image is requested by ID, they will receive the same data every time." but there are no ways to get list of images including 'deleted' or details of 'deleted' image, e.g. doka@lagavulin(admin@admin):~$ openstack image show b179ecee-775d-4ee4-81c0-d3ec3a769d35 Could not find resource b179ecee-775d-4ee4-81c0-d3ec3a769d35 so preserving image record in database makes no sense for 3rd party services, which talk to Glance over public API. On the other hand, having in DB API ready for use 'image_destroy' call, it's pretty easy (of course, for those who work with Glance code :-) ) to add public API call kind of images/{image_id}/actions/destroy , calling DB API's image_destroy. And, in that case, it makes sense to allow image uuid to be specified during image create (since client can purge specified record and recreate it using same characteristics), otherwise I don't see where, in general, specifying uuid (when creating image) can be useful. The good news is that I solved my problem. The bad news is that solution relies on relaxed requirements of 3rd party products but not on Glance's API itself :-) Thanks! On 6/5/19 5:38 PM, Brian Rosmaita wrote:
On 6/5/19 8:34 AM, Volodymyr Litovka wrote:
Dear colleagues,
for some reasons, I need to shrink image size to zero (freeing storage as well), while keeping this record in Glance database.
First which come to my mind is to delete image and then create new one with same name/uuid/... and --file /dev/null, but this is impossible because Glance don't really delete records from database, marking them as 'deleted' instead. The glance-manage utility program allows you to purge the database. The images table (where the image UUIDs are stored) is not purged by default because of OSSN-0075 [0]. See the glance docs [1] for details.
[0] https://wiki.openstack.org/wiki/OSSN/OSSN-0075 [1] https://docs.openstack.org/glance/latest/admin/db.html#database-maintenance
(That doesn't really help your issue, I just wanted to point out that there is a way to purge the database.)
Next try was to use glance image-upload from /dev/null, but this is also prohibited with message "409 Conflict: Image status transition from [activated, deactivated] to saving is not allowed (HTTP 409)" That's correct, Glance will not allow you to replace the image data once an image has gone to 'active' status.
"image_destroy" but have no clues on how to access this API. Is it kind of library or kind of REST API, how to access it and whether it's safe to use it in terms of longevity and compatibility between versions? The title of that document is misleading. It describes the interface that Glance developers can use when they need to interact with the database. There's no tool that exposes those operations to operators.
Or, may be, you can advise any other methods to solve the problem of zeroing glance image data / freeing storage, while keeping in database just a record about this image? If you purged the database, you could do your proposal to recreate the image with a zero-size file -- but that would give you an image with status 'active' that an end user could try to boot an instance with. I don't think that's a good idea. Additionally, purging the images table of all UUIDs, not just the few you want to replace, exposes you to OSSN-0075.
An alternative--and I'm not sure this is a good idea either--would be to deactivate the image [2]. This would preserve all the current metadata but not allow the image to be downloaded by a non-administrator. With the image not in 'active' status, nova or cinder won't try to use it to create instances or volumes. The image data would still exist, though, so you'd need to delete it manually from the backend to really clear out the space. Additionally, the image size would remain, which might be useful for record-keeping, although on the other hand, it will still count against the user_storage_quota. And the image locations will still exist even though they won't refer to any existing data any more. (Like I said, I'm not sure this is a good idea.)
[2] https://developer.openstack.org/api-ref/image/v2/#deactivate-image
Thank you. Not sure I was much help. Let's see if other operators have a good workaround or a need for this kind of functionality.
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
On 6/6/19 6:49 AM, Volodymyr Litovka wrote: [snip]
But in fact, Glance has a bit contradictory approach:
Documentation on db purge says: "Remember that image identifiers are used by other OpenStack services that require access to images. These services expect that when an image is requested by ID, they will receive the same data every time." but there are no ways to get list of images including 'deleted' or details of 'deleted' image, e.g.
doka@lagavulin(admin@admin):~$ openstack image show b179ecee-775d-4ee4-81c0-d3ec3a769d35 Could not find resource b179ecee-775d-4ee4-81c0-d3ec3a769d35
That's correct, Glance lets you know that an image doesn't exist anymore by returning a 404.
so preserving image record in database makes no sense for 3rd party services, which talk to Glance over public API.
That's right, Glance keeps this data around for its own internal bookkeeping purposes, namely, to ensure that an image_id isn't reused. (A design decision was made when the v2 API was introduced in Folsom not to expose deleted image records to end users. I think the idea was that "cloudy" behavior would entail lots of image creation and deletion, and there was no sense clogging up the database. This was before the discovery of OSSN-0075, however.)
On the other hand, having in DB API ready for use 'image_destroy' call, it's pretty easy (of course, for those who work with Glance code :-) ) to add public API call kind of images/{image_id}/actions/destroy , calling DB API's image_destroy. And, in that case, it makes sense to allow image uuid to be specified during image create (since client can purge specified record and recreate it using same characteristics), otherwise I don't see where, in general, specifying uuid (when creating image) can be useful.
The use case I've seen for specifying the uuid is where a provider has multiple independent clouds and wants to make it easy for an end user to find the "same" public image in each cloud. Unlike image_ids, there is no uniqueness requirement on image names. OSSN-0075 is the reason why we don't expose an destroy action through the API. A user could post a useful image with image_id 1, share it or make it a community image, then after a sufficient number of people are using it, replace it with a completely different image with some kind of malicious content, keeping all the other metadata (id, name, etc.) identical to the original image (except for the os_hash_value, which would definitely be different).
The good news is that I solved my problem. The bad news is that solution relies on relaxed requirements of 3rd party products but not on Glance's API itself :-)
Glad you solved your problem! I think I don't quite grasp your use case, but I'm glad you got something working.
Thanks!
On 6/5/19 5:38 PM, Brian Rosmaita wrote:
On 6/5/19 8:34 AM, Volodymyr Litovka wrote:
Dear colleagues,
for some reasons, I need to shrink image size to zero (freeing storage as well), while keeping this record in Glance database.
First which come to my mind is to delete image and then create new one with same name/uuid/... and --file /dev/null, but this is impossible because Glance don't really delete records from database, marking them as 'deleted' instead. The glance-manage utility program allows you to purge the database. The images table (where the image UUIDs are stored) is not purged by default because of OSSN-0075 [0]. See the glance docs [1] for details.
[0] https://wiki.openstack.org/wiki/OSSN/OSSN-0075 [1] https://docs.openstack.org/glance/latest/admin/db.html#database-maintenance
(That doesn't really help your issue, I just wanted to point out that there is a way to purge the database.)
Next try was to use glance image-upload from /dev/null, but this is also prohibited with message "409 Conflict: Image status transition from [activated, deactivated] to saving is not allowed (HTTP 409)" That's correct, Glance will not allow you to replace the image data once an image has gone to 'active' status.
"image_destroy" but have no clues on how to access this API. Is it kind of library or kind of REST API, how to access it and whether it's safe to use it in terms of longevity and compatibility between versions? The title of that document is misleading. It describes the interface that Glance developers can use when they need to interact with the database. There's no tool that exposes those operations to operators.
Or, may be, you can advise any other methods to solve the problem of zeroing glance image data / freeing storage, while keeping in database just a record about this image? If you purged the database, you could do your proposal to recreate the image with a zero-size file -- but that would give you an image with status 'active' that an end user could try to boot an instance with. I don't think that's a good idea. Additionally, purging the images table of all UUIDs, not just the few you want to replace, exposes you to OSSN-0075.
An alternative--and I'm not sure this is a good idea either--would be to deactivate the image [2]. This would preserve all the current metadata but not allow the image to be downloaded by a non-administrator. With the image not in 'active' status, nova or cinder won't try to use it to create instances or volumes. The image data would still exist, though, so you'd need to delete it manually from the backend to really clear out the space. Additionally, the image size would remain, which might be useful for record-keeping, although on the other hand, it will still count against the user_storage_quota. And the image locations will still exist even though they won't refer to any existing data any more. (Like I said, I'm not sure this is a good idea.)
[2] https://developer.openstack.org/api-ref/image/v2/#deactivate-image
Thank you. Not sure I was much help. Let's see if other operators have a good workaround or a need for this kind of functionality.
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
participants (2)
-
Brian Rosmaita
-
Volodymyr Litovka