-
Notifications
You must be signed in to change notification settings - Fork 27
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
Optimize memory usage of unpacking FBC from pod logs #22
Comments
FWIW I attempted to resolve this with 7abf80b#diff-025e5ad2e9e8e55336b0ed5c705b28593c6e6fa342ca89c0ace5e784cd708b2bL298-R394 and the result was that not all objects from the FBC were read before returning. This may indicate that we need to make a change in operator-registry to ensure that when loading from a reader we are reading until we have read everything |
@joelanford I don't think this is an issue anymore due to the change to using the |
It seems like we still have a similar problem in the unpacker implementation for images: catalogd/internal/source/image.go Lines 249 to 253 in a8f7196
However, I think the solution is to replace the pod-based image unpacker with a registry client implementation. Shall we go ahead and embark on that path? I created #143 to describe the idea. |
This should be superseded by #143 right? |
In these lines, we copy the logs to a byte buffer, and then turn around and create a reader from the byte buffer.
We may be able to avoid the buffer entirely by feeding the podLog stream directly into
declcfg.LoadReader
.Acceptance Criteria:
The text was updated successfully, but these errors were encountered: