pfp: recorder: add maxSize and coalescing options
#99
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: shajmakh The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ffromani
reviewed
Oct 6, 2025
| } | ||
|
|
||
| func (rs RecordedStatus) Size() int { | ||
| byteCount, _ := fmt.Fprint(io.Discard, fmt.Sprintf("%+v\n%+v", rs.Pods, rs.RecordTime)) |
Member
Author
There was a problem hiding this comment.
do you mean that we should replace it with calculating that ourselves like you originally did? I thought go fmt provides bytesize for free so why not to use it if we are dumping the output to io.Discard
shajmakh
force-pushed
the
add-more-options
branch
3 times, most recently
from
bba0e9a to
41f345f
Compare
Support new option that if set to true it would configure the recorders to push PFP statuses only if they are unique in PFP values compared to the last existing status, otherwise it just skips pushing the status. Note that this option works only for the last recorded status and it does not affect other statuses in the stack. Signed-off-by: Shereen Haj <shajmakh@redhat.com>
Place Recorder and NodeRecorder options in one file for easier navigation. Signed-off-by: Shereen Haj <shajmakh@redhat.com>
Allow to configure the NodeRecorder with maximum capacity to avoid extreme growth in recorded PFP statuses size. This is yet another sealing besides maxCapacity that the node recorder should not cross. The maxSize takes precesdence over maxCapacity, meaning as long as the current size of the nodeRecorder does not reach the maximum allowed, `statuses` slice length is maintained and is allowed to reach the maximum capacity. Once the new item pushed to the nodeRecorder is expected to make the recorder reach the max allowed size, `statuses` will witness reductions in older items to allow the new status to fit, under the constraint that node recorder will at least have one status no matter its size. So the boundary is important but the recorder goal should still be on top. Signed-off-by: Francesco Romani <fromani@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extend the recorder to be configured with 2 more options:
see the commits for more context.