Open DavidS opened 4 years ago
In order to allow the cache to be accessed from the provider itself (for example, how SimpleProvider does it) I think that the cache has to also be exposed at least enough so that the provider can retrieve a resource state via the cache.
As part of this, I propose exposing a get()
style method which can access the cache. Given the RSAPI design it feels like it maybe should (needs?) to live in context
. Thoughts?
I've just experienced a performance issue and noticed the lack of caching... can we please get this soonish? :)
When puppet processes a catalog for resources that are not marked for purging, the
instances
method is not called, and instead puppet callsretrieve
for every resource individually:this causes excessive calls to the underlying provider and API, and slows down operations significantly.
The result from the
get
calls in resource_api.rb#L342-L344 need to be cached and only be called if there is a cache miss. In the case of non-simple_get_filter
, cache misses are authoritative after the firstget
call.Special care must be taken that the cache has the right scope (provider), as cursory testing seemed to indicate that regular class-level variables (
@@rsapi_cache
) are shared across all types. See https://github.com/puppetlabs/puppet-resource_api/blob/6f5fc1ab065ca0ef2ee80cf1c50eab93e92f78fb/lib/puppet/resource_api.rb#L59 for a possible solution approach.Additional Context
Originally filed as https://tickets.puppetlabs.com/browse/PDK-1234