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.

get_instances(cached_headers, ... <currently existing args such as tenant-id>) == > in this scheme the object server does the determination of what to send. A final merge must happen at the client. Merge is typically for lists. No merge for singleton object refreshes. Refresh could be recursive for complex objects with aggregates and sub-objects. It may be a good idea to support cached objects for cases where significant benefit is expected .. things typically displayed in management dashboards. merge(cache, retrieved_objects)

Alternately the client can request headers from the object server and then determine which complete objects to retrieve and do a final merge on receipt. get_all_instances( .., headers_only=true)

The refresh method essentially does a compare of the cached copy of an object (using the object-id) based on its updated_at value with the latest greatest in the respository per its updated_at value.

When there are many objects, possibly with aggregates of subjects with few of them changing, this caching is useful.

Occasionally displays have a table abstract view and a more detailed view. It may be useful to add an API that requests only some fields of any object to support the abstract view. get_all_instances(field1, field2 ..)