-
Notifications
You must be signed in to change notification settings - Fork 54
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
Use catalogd HTTP Server instead of CatalogMetadata
API
#411
Use catalogd HTTP Server instead of CatalogMetadata
API
#411
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #411 +/- ##
==========================================
- Coverage 84.42% 76.77% -7.66%
==========================================
Files 23 21 -2
Lines 777 788 +11
==========================================
- Hits 656 605 -51
- Misses 86 148 +62
Partials 35 35
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
e94fddd
to
f70e35b
Compare
CatalogMetadata
APICatalogMetadata
API
IIUC the plan is to hold this PR on a catalogd release that contains operator-framework/catalogd#168 and that caching logic should be added. Due to this I will be placing a hold on this PR /hold |
@everettraven please mark it as a draft PR - we don't use Prow on this repo. Thanks! |
Do I read correctly that now we're caching the full contents of every catalog in memory? |
Correct, but I'm actively working on a different caching mechanism that will use the local filesystem for caching the contents and in-memory cache for some additional information that won't exist in the cached file. |
Technically, we are doing that on |
FetchCatalogContents(ctx context.Context, catalog *catalogd.Catalog) (io.ReadCloser, error) | ||
} | ||
|
||
func New(cl client.Client, fetcher Fetcher) *Client { |
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 called this thing "client" due to lack of imagination on my side. Don't hesitate to rename, if you feel like it & have a better name in mind.
1ae9b4a
to
fcb56fd
Compare
Looks like actions are hung up - closing and re-opening to kick them |
fcb56fd
to
038505c
Compare
038505c
to
5411ba6
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 it looks good to me, but I haven't looked into tests just yet. Hoping to come back to this tomorrow.
5411ba6
to
1427f79
Compare
/hold cancel |
rc, err := c.FetchCatalogContents(ctx, tst.catalog) | ||
assert.NoError(t, err) | ||
defer rc.Close() | ||
data, err := io.ReadAll(rc) | ||
assert.NoError(t, err) | ||
assert.Equal(t, tst.contents, data) |
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 can see how these extra tests provide coverage of the cache code, but unless I'm missing something, they don't actually verify whether cached data or fetched data is returned.
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.
You're correct on this one - I missed forcing an update to the contents returned by the mock http.RoundTripper. The test below verifies this by ensuring the contents returned by the function are the same as the contents that should be returned by the http.RoundTripper
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.
For more clarity, the logic behind this is:
- If tst.tripper.content is changed and the cache is not used the content that will be returned != tst.contents
- If tst.tripper.content is changed and the status.resolvedSource.image.ref is changed it won't hit the cache and thus the response should be different than original contents and instead match what the tst.tripper is told to return.
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've updated the code a bit to try and make this more clear when reading it)
contents []byte | ||
wantErr bool | ||
tripper *MockTripper | ||
extraTests func(t *testing.T, c client.Fetcher, ctx context.Context, tst test) |
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've not seen this pattern before, and I'm worried it might be confusing, ripe for misuse later, or become an abstraction that is no longer useful and that we keep carrying because it's here.
WDYT of factoring these into tests into separate Test*
functions or t.Run
blocks that just do a series of things in order?
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.
TLDR: I'd prefer this be done in a follow-up if acceptable since this follows the table driven testing the rest of the catalogmetadata
package seems to follow for multiple tests of the same method.
The thinking here was that this would be a function signature used to run a few extra validation/test steps and at it's base, all of these test cases have to go through the same initial run. The idea was to reduce code repetition while still achieving the ability to do some additional testing steps for the, currently, 2 tests that need it.
I'd prefer to keep this as is for now since it follows the same table driven testing pattern that exists in the rest of the catalogmetadata
package and reduces code repetition.
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'm not opposed to table-driven, but that sort of hits on my concern. This isn't totally table-driven because the table actually contains more test code rather then being more declarative/static test input/expectations.
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.
If I'm the only one with this concern, I won't hold this PR up on it though.
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.
That's a fair point - I'm still new to the table driven testing pattern so I wasn't aware this was actually an anti-pattern for it. Thanks for pointing it out, til :)
Changed it in 76c9cc8 - let me know if this addresses your concerns
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.
One more nit I mentioned above, but looks good. Thanks for sticking with it!
Signed-off-by: Bryce Palmer <[email protected]>
76c9cc8
to
e0aede3
Compare
We ended up pulling in the status.contentURL
feature from catalogd to resolve the related suggestion.
05ffd85
Description
catalogd
dependency tov0.7.0
internal/catalogmetadata
package to make HTTP requests to the catalogd HTTP server that serves catalog contents instead of using the deprecatedCatalogMetadata
APIinternal/resolution/entitysources/catalogdsource.go
implementation to also make HTTP requests (didn't do any optimization work here since it is planned to be removed by Remove Entities and EntitySources #413)Reviewer Checklist