Show Table of Contents
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
glanceconfiguration files, usually stored in
glance-cacheis deployment specific, and depending on the store that is being used, it is possible that having
glance-cachemay not provide any benefit.
Advantages and Disadvantages of having
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
Disadvantge - Depending on the store, duplication of the data in your cloud as the image data will be downloaded in the
glance-cachenode. 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.iniin 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.inifile as follows:
[pipeline:glance-api-caching] pipeline = versionnegotiation context cache apiv1app
To enable the above application parameter, in your main
glance-api.confconfiguration file, select the appropriate deployment flavor as follows:
[paste_deploy] flavor = caching
8.3.2. Enable the Image Cache Management
There is an optional
cachemanageoption 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
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
Table 8.22. Description of Image Cache configuration options
|Configuration option = Default value||Description|
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
(Optional) The default
(Optional) When using the
(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
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
cindertenant manually for image cache, by setting the following parameter values in the
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.
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.