Provision for immediate caching of an image

Include the URL of your launchpad blueprint:

Provision for immediate caching of a given image on a particular glance node.

Problem description

In Yoga we have added support for caching related operations under V2 API, but still we need to depend on existing periodic job to cache the actual image. This means user/deployer/admin needs to wait until next periodic job to run for caching of an actual image. Even though default time for periodic job is 300 seconds (5 minutes) it may vary deployment wise and the user has to wait until the actual image is cached.

Proposed change

We are proposing to remove existing periodic job from glance-api and modify existing PUT /v2/cache/{image_id} API which will queue an image for caching and start caching it immediately. If any existing instant caching operation is in progress then the latest image will be added to the queue so that it will be picked up for caching as soon as previous operation completes. User can use GET /v2/cache API call to see the size of the queue.


Instead of modifying existing API, we can add a new POST API which will start immediate caching of specified image. We can use existing policy cache_image so that user with appropriate permissions can perform this operation. To make the policy compatible with secure RBAC we need to pass required parameters like ImageTarget while enforcing the policy. It is recommended to keep cache_image operation limited to admin use only.

Another alternative solution could be, instead of removing the old periodic job, the new API should trigger the periodic job instantly to cache all the images rather than just caching a specified image at a time. This solution need to be thread safe as there might be a chance of existing periodic job is already running or new periodic job will start running while we trigger the same via API.

Data model impact


REST API impact


Security impact


Notifications impact


Other end user impact


Performance Impact


Other deployer impact

Caching is and will remain local to each glance node and as this command will be executed remotely, operator needs to know the direct URL of each glance node which are behind the load balancer. Operator needs to provide this direct URL to glanceclient so that client should hit particular node to trigger immediate caching on that node.

Developer impact




Primary assignee:

dansmith or abhishekk

Other contributors:




Work Items

  • Modify existing API (PUT /v2/cache/{image_id})

  • Remove the ‘cache_prefetcher_interval’ config option and related tests.

  • Modify documentation, update API reference

  • Tempest coverage for Caching operations




  • All new cache API should be tested using tempest tests

Documentation Impact

  • The API documentation will need to be updated

  • Need to update Cache documentation as well with new information