Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

8.3. Configure Image Cache

You can configure the Image service API to have a local image cache. Caching of image files is transparent and can be performed by modifying some configuration parameters.
These parameters are configured in the PasteDeploy configuration file, component-paste.ini. You should not generally edit this file directly, as it ships with default options for all common deployment flavors. The PasteDeploy configuration file is stored with the rest of the glance configuration files, usually stored in /etc/glance or /usr/share/glance.
Note
Using glance-cache is deployment specific, and depending on the store that is being used, it is possible that having glance-cache may not provide any benefit.
Advantages and Disadvantages of having glance-cache
Advantage - It creates locality for the image data. It brings the data closer to the compute node and avoid having to download it every time from glance-api. Therefore, requests would be spread across the cache node and not go directly to glance-api.
Disadvantge - Depending on the store, duplication of the data in your cloud as the image data will be downloaded in the glance-cache node. Therefore, it is necessary to account for the extra storage when provisioning the cloud.

8.3.1. Enable the Image Cache

To enable the image cache parameters, the cache parameters must occur in the application pipeline after the appropriate context parameters. A pipeline is a series of middlewares that will be executed whenever a request hits the API.
The cache parameters should be in your glance-api-paste.ini in a section titled [filter:cache]. It should look like this:
[filter:cache]
paste.filter_factory = glance.api.middleware.cache:CacheFilter.factory
A ready-made application parameter including this filter is defined in the glance-api-paste.ini file as follows:
[pipeline:glance-api-caching]
pipeline = versionnegotiation context cache apiv1app
To enable the above application parameter, in your main glance-api.conf configuration file, select the appropriate deployment flavor as follows:
[paste_deploy]
flavor = caching

8.3.2. Enable the Image Cache Management

There is an optional cachemanage option that allows you to directly interact with cache images. Use this flavor in place of the cache flavor in your API config file.
[paste_deploy]
flavor = cachemanage
Note
For example, the following setting enables a pipeline (configured in the .ini file) that has both, keystone and cachemanagement, enabled.
[paste_deploy]
flavor = keystone+cachemanage

8.3.3. Configuration Options Affecting the Image Cache

These configuration options must be set in both the glance-cache and glance-api configuration files.

Table 8.21. Description of Image Cache configuration options

Configuration option = Default value Description
image_cache_dir = /var/lib/glance/image-cache Required when image cache middleware is enabled. This is the base directory the image cache can write files to. Make sure the directory is writable by the user running the glance-api server.
image_cache_driver = sqlite (Optional) The default sqlite cache driver has no special dependencies, other than the python-sqlite3 library, which is installed on almost all operating systems with modern versions of Python. It stores information about the cached files in a SQLite database.
The xattr cache driver requires the python-xattr>=0.6.0 library and requires that the filesystem containing image_cache_dir has access times tracked for all files (in other words, the noatime option CANNOT be set for that filesystem). In addition, user_xattr must be set on the filesystem’s description line in fstab.
image_cache_sqlite_db = cache.db (Optional) When using the sqlite cache driver, you can set the name of the database that will be used to store the cached images information. The database is always contained in the image_cache_dir .
image_cache_max_size = 10737418240 (10 GB) (Optional) Size, in bytes, that the image cache should be constrained to. Images files are cached automatically in the local image cache, even if the writing of that image file would put the total cache size over this size. The glance-cache-pruner executable is what prunes the image cache to be equal to or less than this value. The glance-cache-pruner executable is designed to be run via cron on a regular basis.

8.3.4. Configure Image-Volume Cache

OpenStack Block Storage has an optional Image cache which can dramatically improve the performance of creating a volume from an image. The improvement depends on many factors, primarily on how quickly the configured back-end can clone a volume.
When a volume is first created from an image, a new cached image-volume will be created that is owned by the Block Storage internal tenant. Subsequent requests to create volumes from that image will clone the cached version instead of downloading the image contents and copying data to the volume.
The cache itself is configurable per back end and will contain the most recently used images.
The Image-Volume cache requires that the internal tenant be configured for the Block Storage services. This tenant will own the cached image-volumes so they can be managed like normal users including tools like volume quotas. This protects normal users from having to see the cached image-volumes, but does not make them globally hidden.
The administrator should configure the new internal cinder tenant manually for image cache, by setting the following parameter values in the cinder.conf file.
cinder_internal_tenant_project_id=PROJECT_ID
cinder_internal_tenant_user_id=USER_ID
This tenant will store the cached image volumes so they can be managed like normal users. It protects normal users from having to see the cached image volumes.
Note
The actual user and project that are configured for the internal tenant do not require any special privileges. They can be the Block Storage service tenant or can be any normal project and user.