-
Notifications
You must be signed in to change notification settings - Fork 249
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
pkg/cache: support creating a json cache directly from a model.Model #1111
pkg/cache: support creating a json cache directly from a model.Model #1111
Conversation
Signed-off-by: Joe Lanford <[email protected]>
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: joelanford 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 |
if err := os.WriteFile(filepath.Join(q.baseDir, jsonDigestFile), []byte(digest), jsonCacheModeFile); err != nil { | ||
return err | ||
} |
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.
Maybe we should create an empty digest file in the case that we're loading from a model?
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.
Would this be done in LoadJSONFromModel
?
Would you ever do a integrity check when you're loaded directly from a model?
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 mean from my perspective I'd call LoadJSONFromModel
with a temporary directory and throw the directory away when I am done.
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.
Would you ever do a integrity check when you're loaded directly from a model?
I don't think so. The digest is a combination of the filesystem contents of the FBC and the cache, so if either change, then the cache is invalid. In this case, we have no FBC filesystem, so the integrity check doesn't make sense.
I mean from my perspective I'd call LoadJSONFromModel with a temporary directory and throw the directory away when I am done.
Yes, that would be the expected use of this function. But I'm not happy with the API because it never makes sense to do anything other than that. In which case, why ask the caller to pass a directory in? Ideally, the temporary directory would be an implementation detail not exposed in the API. But then how does the caller clean up when they're done? The Cache
API design expects the cache to be re-usable and saved for later, so there is no Close()
or Cleanup()
method in the cache API or in the JSON cache struct.
Maybe need a higher level abstraction that uses a cache under the hood?
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.
Well, the "magic" happens in the packagesFromModel
function so maybe the easier approach is to expose that publicly and then call the functions on the packageIndex
? This seems to sidestep the caching mechanism entirely if I am not mistaken.
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.
Some of those functions accept a cache though (e.g.
operator-registry/pkg/cache/pkgs.go
Line 62 in 6c60284
func (pkgs packageIndex) GetBundleForChannel(ctx context.Context, c Cache, pkgName string, channelName string) (*api.Bundle, error) { |
So right now, packageIndex
is very much coupled to the cache.
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.
Yeah.. I see that now. My mistake.
Codecov Report
@@ Coverage Diff @@
## master #1111 +/- ##
==========================================
+ Coverage 52.35% 52.59% +0.24%
==========================================
Files 107 108 +1
Lines 9688 9712 +24
==========================================
+ Hits 5072 5108 +36
+ Misses 3674 3661 -13
- Partials 942 943 +1
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Description of the change:
Add
cache.LoadJSONFromModel
Motivation for the change:
We removed functionality during the cache refactor that made it impossible to build a
GRPCQuery
implementation directly from amodel.Model
.This PR adds the ability to so this, specifically in the
cache.JSON
implementation.I'm not convinced this is the best approach. Another approach may be to introduce a new (optional?) interface method, something like
BuildWithModel
that a cache implementation could support. This approach would require some thinking about howcache.New
would work though. Because it returns a "preferred" cache implementation if it detects an empty cacheDir. What if the preferred cache implementation doesn't supportBuildWithModel
?Closes #1116
Reviewer Checklist
/docs