GLANCE-SCRUBBER(1)

📦
version 33.0.0 · 11 versions
, in ubuntu stonking

🎀 NAME 🎀

glance-scrubber — the Glance Scrubber Service, aka the little cleanup fairy that actually deletes your deleted images 💅

✨ GLANCE SCRUB SERVICE ✨

okay so before we even get into it, here's the whole vibe-check card for this page:

  • Author — OpenStack Glance Project Team 🫶
  • Contact — <glance@lists.launchpad.net>
  • Date — 2025-04-02
  • Copyright — OpenStack Foundation
  • Version — 30.0.0
  • Manual section — 1
  • Manual group — cloud computing ☁️

🦋 SYNOPSIS 🦋

glance-scrubber [options]

💖 DESCRIPTION 💖

so glance-scrubber is this utility that lets an operator set Glance up for asynchronous deletion of images, or flip an image's status back from pending_delete to active. whether that even makes sense for your deployment is lowkey a whole question — it depends on the storage backend you're using and how big your typical images are in your Glance installation. like, your mileage genuinely varies ✨

so here's the tea: an image in glance is really two things — an image record (living in the database) and a file of image data (living in a storage backend). under normal operation, the image-delete call is synchronous, which means Glance gets 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 isn't a function of data size, all of this happens basically instantly, no notes 💅

BUT. for backends where deletion time is a function of data size, 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. and that, bestie, leads to user dissatisfaction 😭 not the vibe.

to dodge this whole problem, Glance has a delayed_delete configuration option (False by default) that you can set in the glance-api.conf file. with this option enabled, when Glance receives a DELETE request, it only does the database part of the request — marking the image's status as pending_delete — and returns immediately. (btw the pending_delete status is not visible to users; an image-show request for such an image will return 404.) however!! important!! when delayed_delete is enabled, Glance does not delete image data from the storage backend. and that's exactly 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. fr fr, it will just keep hoarding 💀

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. like, actually. don't.

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 — minimum time in seconds that an image will stay in pending_delete status (default is 0)
  • scrub_pool_size — configures a thread pool so that scrubbing can be performed in parallel (default is 1, that is, serial scrubbing)
  • daemon — a boolean indicating whether the scrubber should run as a daemon (default is False)
  • wakeup_time — time in seconds between runs when the scrubber is run in daemon mode (ignored if the scrubber is not being run in daemon mode)
  • metadata_encryption_key — If your glance-api.conf sets a value for this option (the default is to leave it unset), you must include the same setting in your glance-scrubber.conf or the scrubber won't be able to determine the locations of your image data. 👀
  • restore — reset the specified image's status from 'pending_delete' to 'active' when the image is deleted by mistake.
  • [database] — As of the Queens release of Glance (16.0.0), the glance-scrubber does not use the deprecated Glance registry, but instead contacts the Glance database directly. Thus your glance-scrubber.conf file must contain a [database] section specifying the relevant information.
  • [glance_store] — This section of the file contains the configuration information for the storage backends used by your Glance installation.

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 — main character energy, respect 🫡 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.

🌈 OPTIONS 🌈

✨ General options ✨

  • -h, --help — Show the help message and exit
  • --version — Print the version number and exit
  • -v, --verbose — Print more verbose output
  • --noverbose — Disable verbose output
  • -d, --debug — Print debugging output (set logging level to DEBUG instead of default WARNING level)
  • --nodebug — Disable debugging output
  • --use-syslog — Use syslog for logging
  • --nouse-syslog — Disable the use of syslog for logging
  • --syslog-log-facility SYSLOG_LOG_FACILITY — syslog facility to receive log lines
  • --config-dir DIR — Path to a config directory to pull *.conf files from. This file set is sorted, to provide a predictable parse order if individual options are over-ridden. The set is parsed after the file(s) specified via previous --config-file, arguments hence over-ridden options in the directory take precedence. This means that configuration from files in a specified config-dir will always take precedence over configuration from files specified by --config-file, regardless to argument order.
  • --config-file PATH — Path to a config file to use. Multiple config files can be specified by using this flag multiple times, for example, --config-file <file1> --config-file <file2>. Values in latter files take precedence.
  • --log-config-append PATH, --log-config PATH — The name of logging configuration file. It does not disable existing loggers, but just appends specified logging configuration to any other existing logging options. Please see the Python logging module documentation for details on logging configuration files. The log-config name for this option is deprecated.
  • --log-format FORMAT — A logging.Formatter log message format string which may use any of the available logging.LogRecord attributes. Default: None
  • --log-date-format DATE_FORMAT — Format string for %(asctime)s in log records. Default: None
  • --log-file PATH, --logfile PATH — (Optional) Name of log file to output to. If not set, logging will go to stdout.
  • --log-dir LOG_DIR, --logdir LOG_DIR — (Optional) The directory to keep log files in (will be prepended to --log-file)
  • -D, --daemon — Run as a long-running process. When not specified (the default) run the scrub operation once and then exits. When specified do not exit and run scrub on wakeup_time interval as specified in the config.
  • --nodaemon — The inverse of --daemon. Runs the scrub operation once and then exits. This is the default.
  • --restore <IMAGE_ID> — Restore the specified image status from 'pending_delete' to 'active'.

🍓 FILES 🍓

  • /etc/glance/glance-scrubber.conf — Default configuration file for the Glance Scrubber

👑 SEE ALSO 👑

🙈 BUGS 🙈

💜 Author 💜

OpenStack

2010-present, OpenStack Foundation.

and that's the whole page bestie 🫶 the footer says 33.0.0 and Sep 30, 2026, which is a different number than the 30.0.0 up in the version block — the manpage has two numbers and I am simply reporting both, no notes, I don't make the rules 💅 anyways go run your scrubber, your storage backend will thank you ✨🌸
📦 where this page comes from