-
Notifications
You must be signed in to change notification settings - Fork 1.8k
feat: implement shared cache for bundle, git, and cluster resolvers #9051
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
feat: implement shared cache for bundle, git, and cluster resolvers #9051
Conversation
|
The following is the coverage report on the affected files.
|
|
@twoGiants I have been updating the original PR |
|
I will contribute here instead |
05fe2d2 to
4bc9258
Compare
|
/retest |
2 similar comments
|
/retest |
|
/retest |
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.
Looking good, still some questions/comments and todos
- There is still some TODOs (the DEPRECATED functions in
pkg/remoteresolution/cachepackage) - I am not a huge fan of loading the configmap when we start and not do anything else. I would prefer if we do the same as we do for the other configmap, we watch it from the controller, and we adapt from changes.
- As it is today, if you change the configuration for cache, you need to restart the deployment of resolvers
- If someone wants to enable cache on a running instance, same then, a manual intervention is needed
| TTL: r.ttl, | ||
| Params: params, | ||
| // IsImmutable implements ImmutabilityChecker.IsImmutable | ||
| // Returns true if the revision parameter is a commit SHA (40-character hex string) |
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.
Quick note : as of today, a full git SHA is SHA-1, but tomorrow (git v3), it would/could but SHA-256, so we could try to take this case into account today already ? (or create a follow-up issue)
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.
@waveywaves ☝️ 😸
5ee1911 to
f06cf00
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.
I think we are good. There might be a few nits that we can do in a follow-up.
We will also need to stash some commits a bit, there is too much right now 🙃
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
6aa0c9c to
0224721
Compare
0224721 to
23cba41
Compare
|
/retest |
28ea88c to
aa83b01
Compare
Implements a shared, thread-safe LRU cache with TTL expiration for Tekton resolvers (bundle, git, cluster). All resolvers share a single cache instance configured via ConfigMap with hot-reload support. Features: - Shared singleton cache across all resolver types - ConfigMap-based configuration (max-size, ttl) - Three cache modes: always, never, auto (immutability detection) - Thread-safe concurrent access with proper locking - Content-addressable keys using SHA-256 hashing - Observability via annotations (cache hit/miss, timestamps) - Clock interface for testable timestamp generation Testing: - Unit tests for cache operations, TTL, LRU eviction - Race detector tests for concurrent access - E2E tests for end-to-end cache behavior - High-load concurrency tests (1000 goroutines) Implementation uses k8s.io/apimachinery LRUExpireCache with ConfigMap watching for dynamic reconfiguration without restart. Co-authored-by: Brian Cook <[email protected]> Co-authored-by: Stanislav Jakuschevskij <[email protected]> Co-authored-by: Vibhav Bobade <[email protected]> Co-authored-by: AI Assistant <[email protected]>
b6d58c3 to
aefb3c1
Compare
aefb3c1 to
97db47e
Compare
97db47e to
9396379
Compare
08e8c3a to
4b40ad4
Compare
4b40ad4 to
ded85a8
Compare
991f504 to
401f09f
Compare
|
/retest |
1 similar comment
|
/retest |
|
/lgtm |
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.
This didn't change anything but make the cacheConfig and its properties public. @waveywaves
Changes
This PR takes the state of PR #8825, starting from commit f817655 (actually 087c5a5 but the first is the big important one) and adds the re-work from the second review of @twoGiants on top of it.
All resolved comments are marked with a 👍 and a "resolved" comment.
What is left to do?
InitializeFromConfigMapand implement functionality => maybe inResolver.Initializepkg/remoteresolution/resolver/cluster/resolver_test.go:TestResolveframework/cache/**Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes