Author: | OpenStack Glance Project Team |
---|---|
Contact: | openstack-discuss@lists.openstack.org |
Date: | 2018-08-30 |
Copyright: | OpenStack Foundation |
Version: | 17.0.0 |
Manual section: | 1 |
Manual group: | cloud computing |
glance-scrubber [options]
glance-scrubber is a utility that allows an operator to configure Glance for the asynchronous deletion of images or to revert the image’s status from pending_delete to active. Whether this makes sense for your deployment depends upon the storage backend you are using and the size of typical images handled by your Glance installation.
An image in glance is really a combination of an image record (stored in the database) and a file of image data (stored in a storage backend). Under normal operation, the image-delete call is synchronous, that is, Glance receives the DELETE request, deletes the image data from the storage backend, then deletes the image record from the database, and finally returns a 204 as the result of the call. If the backend is fast and deletion time is not a function of data size, these operations occur very quickly. For backends where deletion time is a function of data size, however, the image-delete operation can take a significant amount of time to complete, to the point where a client may timeout waiting for the response. This in turn leads to user dissatisfaction.
To avoid this problem, Glance has a delayed_delete
configuration option
(False by default) that may be set in the glance-api.conf file. With this
option enabled, when Glance receives a DELETE request, it does only the
database part of the request, marking the image’s status as pending_delete
,
and returns immediately. (The pending_delete
status is not visible to
users; an image-show request for such an image will return 404.) However, it
is important to note that when delayed_delete
is enabled, Glance does not
delete image data from the storage backend. That’s where the glance-scrubber
comes in.
The glance-scrubber cleans up images that have been deleted. If you run Glance
with delayed_delete
enabled, you must run the glance-scrubber
occasionally or your storage backend will eventually fill up with “deleted”
image data.
The glance-scrubber can also revert a image to active if operators delete
the image by mistake and the pending-delete is enabled in Glance. Please make
sure the glance-scrubber
is not running before restoring the image to avoid
image data inconsistency.
Configuration of glance-scrubber is done in the glance-scrubber.conf file. Options are explained in detail in comments in the sample configuration file, so we only point out a few of them here.
scrub_time
pending_delete
status (default is 0)scrub_pool_size
daemon
wakeup_time
metadata_encryption_key
restore
[database]
[glance_store]
The usual situation is that whatever your glance-api.conf has for the
[database]
and [glance_store]
configuration groups should go into your
glance-scrubber.conf, too. Of course, if you have heavily customized your
setup, you know better than we do what you are doing. The key thing is that
the scrubber needs to be able to access the Glance database to determine what
images need to be scrubbed (and to mark them as deleted once their associated
data has been removed from the storage backend), and it needs the glance_store
information so it can delete the image data.
General options
-h, --help
--version
-v, --verbose
--noverbose
-d, --debug
--nodebug
--use-syslog
--nouse-syslog
--syslog-log-facility SYSLOG_LOG_FACILITY
--config-dir DIR
--config-file PATH
--log-config-append PATH
--log-config PATH
--log-format FORMAT
--log-date-format DATE_FORMAT
--log-file PATH, --logfile PATH
--log-dir LOG_DIR, --logdir LOG_DIR
The inverse of –daemon. Runs the scrub operation once and then exits. This is the default.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.