Open Stack

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.

> 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?

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
> 
>