repository·master·Indexed 19 days ago
https://github.com/openstack/glanceOpenStack Glance is an image service that provides the infrastructure to store, manage, and distribute bootable disk images and associated metadata for OpenStack compute resources. Documentation covers the Metadata Definitions Service (metadefs), deployment options using uWSGI and mod_wsgi, Keystone authentication configuration, and the management of the Glance Image Cache, including pruning, cleaning, and listing cached images.
The OpenStack Image service (glance) is a central component of Infrastructure-as-a-Service (IaaS) that allows users to discover, register, and retrieve virtual machine images. It provides a REST API for querying image metadata and retrieving actual image files.
Key capabilities include:
OpenStack Glance (the Image service) is a service used to upload, discover, and retrieve data assets, primarily virtual machine (VM) images. It provides a RESTful API for querying image metadata and retrieving the actual image files.
Glance supports various storage backends, ranging from local filesystems to object-storage systems like OpenStack Swift.
The glance-replicator utility is used to populate a new Glance server using images from an existing Glance server. When replicating, the images in the destination (slave) server preserve the UUIDs, metadata, and image data from the original (master) server.
glance-replicator <command> [options] [args]The rally-jobs directory contains Rally tasks and plugins used by OpenStack CI. The directory structure is organized as follows:
plugins/: A directory for adding Rally plugins. Since Rally is highly extensible, you can add plugins here for Benchmark contexts, Benchmark scenarios, SLA checks, or Generic cleanup resources.extra/: Files in this directory are copied to the gates environment. This allows you to use absolute paths in your Rally tasks, as these files will be accessible at ~/.rally/extra/*.glance.yaml: A specific task designed to be run in gates against an OpenStack (nova network) deployment provided by DevStack.The Glance project is composed of three primary deliverables. Depending on your goal (API usage, storage backend development, or client integration), you should refer to the specific repository and documentation for that component:
The glance-scrubber is a utility used to manage the asynchronous deletion of images in Glance.
When the delayed_delete option is enabled in glance-api.conf, a DELETE request from a client only marks the image status as pending_delete in the database and returns immediately. This prevents client timeouts on large images, but Glance does not delete the actual image data from the storage backend when delayed_delete is active.
Use glance-scrubber to:
pending_delete to prevent the storage backend from filling up.pending_delete back to active if it was deleted by mistake.Warning: If you are restoring an image, ensure the glance-scrubber is not running to avoid data inconsistency.
The glance-manage tool loads configuration from two files:
glance-api.confglance-manage.confWarning: Options defined in glance-manage.conf will override options with the same section and name in glance-api.conf. It is recommended to migrate configuration options for glance-manage into glance-manage.conf rather than relying on the API config.
In OpenStack, the Image service (Glance) manages the storage and lifecycle of disk images, which serve as templates for virtual machines.
Key concepts include:
Glance implements per-tenant resource consumption quotas using Keystone's unified limits functionality. Instead of global limits, resource limits are registered in Keystone and can be overridden for specific tenants.
Key behaviors to note:
user_storage_quota limit will be ignored.During a zero-downtime upgrade, the database version identifier is composite, reflecting the current stage of the E-M-C cycle. An identifier will explicitly contain expand or contract in its name.
A database is only considered to be at a specific release version (e.g., Ocata) once both the expand and contract revisions for that release are at their latest versions.
Example progression for a 'bexar' release cycle:
| Stage | Identifier | Comment |
|---|---|---|
| E (Expand) | bexar_expand01 | Upgrade begins |
| E | bexar_expand02 | |
| E | bexar_expand03 | |
| M (Migrate) | bexar_expand03 | bexar_migrate01 occurs |
| M | bexar_expand03 | bexar_migrate02 occurs |
| M | bexar_expand03 | bexar_migrate03 occurs |
| C (Contract) | bexar_expand03, bexar_contract01 | |
| C | bexar_expand03, bexar_contract02 | |
| C | bexar_expand03, bexar_contract03 | Upgrade completed |
Metadata definitions are linked to specific Resource Types to drive UI and CLI views. Because different services often require different prefixes for the same underlying property, the API allows you to retrieve the correct prefixed key based on the target resource type.
Examples of prefix variations:
| Property | Resource Type | Required Prefix |
|---|---|---|
| Virtual CPU Topology | Glance Image | hw_ (e.g., hw_cpu_cores=1) |
| Virtual CPU Topology | Nova Flavor | hw: (e.g., hw:cpu_cores=1) |
Scoped Property (companyx:fastio) | Host Aggregate | (none) (e.g., companyx:fastio=true) |
Scoped Property (companyx:fastio) | Nova Flavor (for AggregateInstanceExtraSpecsFilter) | aggregate_instance_extra_specs: (e.g., aggregate_instance_extra_specs:companyx:fastio=true) |