Provision for immediate caching of an image

Change-Id: Ieb793afaa6bf4b7c21729408654ec316ba45d816
Abhishek Kekane 2022-04-20 06:31:48 +00:00
parent aeb0fbf6f4
commit c7bce04f5b
1 changed files with 147 additions and 0 deletions

View File

@ -0,0 +1,147 @@
This work is licensed under a Creative Commons Attribution 3.0 Unported
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