Nova/Object Cache
With the move to objects, there is reduced pressure on the database. Additionally we can reduce network pressure caching objects. This is especially useful for large clouds comprised of many nodes. It essentially leverages the updated_at field in the database that is used to track when an object changed. If a local object copy indicates an earlier updated_at, it must be refreshed, else use with full confidence. Management interfaces such as Horizon frequently retrieve large sets of objects and refresh them frequently (when they are not event based).
Object header lists are tuples of object-id and updated_at.
Consider for instance the Horizon web server caching a list of virtual machine instance objects that it displays. Assume the headers are: {(VM1, t1), (VM2, t2), (VM3, t3) } Assume that only VM2 was updated and a new instance VMk was created. It is adequate to retrieve only these two objects and use them in conjunction with the existing local copies of VM1 and VM3.
Yet another optimization is to retrieve only fields that are expected to be required/used. This would be useful in say a table view where only an abstract view of an object is provided and should the user drill down, a more detail view provided.
Last but not least since some logic is required such as what to retrieve and update the cache, it may be useful to implement caching for objects where we expect savings either from network traffic saved, or network latency to retrieve information etc. Useful for objects that do not change too rapidly.
API changes
- get_instances(headers_only=True/False) or get_objects(object_type, headers_only=TrueFalse)
when headers_only=True the result would be a list of object-id and updated_at tuples. Else a list of object instances in their entirety.
- get_instances(object_id_list)
Only objects retrieved for the object-ids listed
- cache_refresh(local_cache, object_list)
Determining how to refresh the cache should happen at the point of use. It would also save compute resources at the object repository.
