-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce in-memory caching package #766
Conversation
f79844e
to
f5a5a36
Compare
Thanks for working on this, @souleb!
It would be handy to have a link in the code. At the moment this is only mentioned in a commit message and PR description. What may need to be made more explicit is that the sore is persisted to a file. |
There is a comment in Persisting to a file will be made in a follow up PR where we will outline the use case we have for it. |
8eec6c2
to
4ddba8d
Compare
4ddba8d
to
a108669
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks @souleb 🏅
a108669
to
c6ec0fb
Compare
c6ec0fb
to
6b7b355
Compare
0e91350
to
b5172d8
Compare
fb60104
to
eae3ead
Compare
eae3ead
to
f133773
Compare
61b728f
to
fdefd65
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks for all the clarifications and considerations.
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. We also provide a default way to generate keys, but we allow users to provide their own function. This should enable all needed levels of isolation. The provided implementations are an expiring cache and a LRU cache. The cache is self-instrumented. Signed-off-by: Soule BA <[email protected]>
fdefd65
to
d838d8a
Compare
Exciting to see this merged! 🌟 |
This PR will allow caching the authentication credentials retrieved by
pkg/oci/auth
. It should also enable future usage of the caching underlying mechanism.Part of: #642
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 ofkey 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:
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.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: