Currently the various OpenStack projects implement caching (memoization, key-value-store, etc) in a number of various ways. All of the mechanisms for caching should be unified under a single Oslo library oslo.cache.
With the many implementations (and varying degree of flexibility) OpenStack projects should standardize on a single library for caching (memoization, key-value-store, etc) within the code base. Currently, Keystone has used dogpile.cache very successfully. With the flexible backend implementation, dogpile.cache is a natural fit to replace the many different implementations of caching.
The new oslo.cache library would replace the following:
This new module would also open the door for other projects to more easily adopt memoization or other forms of caching.
The oslo.cache module is mostly targeted to be an OpenStack friendly wrapper for dogpile.cache. This will provide a consistent way to cache and memoize data within the OpenStack ecosystem.
The current oslo-incubator oslo openstack.common.cache module would be replaced with an implementation that leverages dogpile.cache library instead of a custom-built system.
This new implementation will provide a mechanism to handle key-value-store (e.g. traditional Memcached) and memoization to begin with.
The Base backends that will be supported are:
The oslo.cache module is intended to provide 3 distinct features above and beyond raw use of dogpile.cache:
Each project that implements either it’s own version of caching using dogpile.cache or other implementations of caching will be converted to use the new oslo.cache module.
This could be left to each project to implement their own caching or develop an OpenStack specific set of modules. Neither of these options are optimal as it requires specific knowledge of the various (or OpenStack specific) caching system to implement a custom backend. With dogpile.cache it is possible to implement a very simple backend and configure it for use with all OpenStack services that make use of the oslo.cache module.
Current APIs should remain unchanged (both in Oslo and in other projects) until caching is implemented. Caching implementation may impact the APIs in some regard (e.g. memoization requires proper invalidation of data).
The current oslo.cache module will remain available but be marked as deprecated. The new oslo.cache implementation will be provided side-by-side for a period of time to allow time for any current consumers of oslo.cache to change-over to the dogpile.cache based implementation.
oslo.cache will provide a fairly simple constructor to access/instantiate the CacheRegion object(s) based upon the configuration built with oslo.cache. There will also be an option to extract the configuration dictionary that can be directly passed to dogpile.cache if a developer chooses to do so.
No direct security implications. Use of the new caching module requires all cached data to be properly invalidated (on change, etc). Stale data could cause security related impact (and thus should be closely reviewed).
Ideally the performance impact of using caching should be only positive, however maintenance of the cache coherency can have overhead when caching is implemented.
It is likely dogpile.cache will have a better performance profile than the current MemoryCache module.
New options for caching will be added. To leverage caching the configuration for a service using oslo.cache will need to have the values set.
By default caching will be disabled (can be overrided by a project) to ensure that memory leaking / improper caching / negative performance impact waiting on non-existent external services will not impact an OpenStack project.
Developers will need to become familiar with dogpile.cache and how to implement usage of memoization and/or key-value-store regions.
Lifecycle will be incubation, and adoption in projects that leverage either dogpile.cache directly (Keystone) or the oslo.MemoryCache module. Once the interfaces are stable (and clearly documented) it is expected this module can quickly move to graduation.
Keystone will be the primary (first target) to adopt the new module (replacing the custom dogpile.cache implementation.
The oslo.MemoryCache module will be updated to leverage the new oslo.cache module.
The direct use of the oslo.MemoryCache module will be deprecated in favor of directly using oslo.cache.
The Library will graduate into a top-level oslo.cache library.
I expect that this library should be able to stabilize within a single development cycle. Adoption via incubator for Kilo and L, release as a library in either K or L.
All dependencies should already be in the global requirements. No external blueprints should be needed.
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode