pkg
pkg copied to clipboard
Auth token caching
This PR will allow caching the authentication credentials retrieved by pkg/oci/auth
. It should also enable future usage of the caching underlying mechanism.
Store design
The store is K/V store that can store arbitrary objects. The store interface is a simplified version of client go store. If an object can be cached there, it should be in our store implementations. This is desirable, because the primary envisioned place for the store usage is during a reconciliation of custom resources retrieved from a shared informer cache.
The keys
are generated dynamically with deterministic function. Accepting a function instead of key strings
enables user to determine themselves the keys uniqueness constraint.
They store must be thread safe, it should support concurrent programs.
There are 2 main uses cases:
-
- cache authentication credentials. A credentials key is written, read and overwritten multiple times by a single goroutine. If we plan to store a credential and refresh it every 6 hours and read every 30 minutes(reconciliation interval), the read/write ratio is 12:1. This is a likely scenario. Authentication credentials are expirable.
-
- cache helm indexes. The new
Store
interface and underlying implementation should allow replacinghttps://github.com/fluxcd/source-controller/tree/main/internal/cache
which is today used to cachehelm indexes
. Ahelm index
is written, read and overwritten multiple times by multiple goroutines. Usually an index is stored and read multiple times (reconciliation of all dependent custom resources * interval) before being overwritten by a new version. It is read intensive. An index is read from local storage before being cached, if the cache is full, we could have several Custom Resources loading the same index in memory, in order to avoid that, we should evict older keys to make room.
- cache helm indexes. The new
Based on the two scenario above, the store should be optimized for reads
.
We also have a scenario that needs keys
to expirable and another that need them be evicted based on usage.
Hence two implementations are provided:
- An expirable store for use case 1
- An LRU cache for use case 2