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
server: refactor debug zip logfiles fetching #30539
base: master
Are you sure you want to change the base?
server: refactor debug zip logfiles fetching #30539
Conversation
bf389df
to
738bdf1
Compare
Use the `GetFiles` endpoint instead for logfile collection instead of using the current enpoint that serves logs in the form of entries. This method is more intuitive with what the zip client actually wants to do. For backwards compatibility reasons, the old method must still be supported. Release note: None
738bdf1
to
8e0c70b
Compare
Hm, this has been sitting for a while. Is @petermattis the right person to review this? |
Put this up one weekend to refactor logfile fetching, I think @andreimatei was familiar with the heap fetching stuff code and suggested we make the change, and so could review this PR. |
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.
LGTM
Reviewable status: complete! 0 of 0 LGTMs obtained
pkg/cli/zip.go, line 302 at r1 (raw file):
ctx, cancel := timeoutCtx(baseCtx) defer cancel() // Use older method of log fetching for backwards compatibility.
pls use more words for this comment - say what the "old" method and the new one are.
Also, this method is way too long and indented already - would you mind extracting all the logs code in a new method (probably with two sub-methods for the two ways of fetching the files
pkg/cli/zip.go, line 334 at r1 (raw file):
} } } else {
nit: put the expected code path first - which is the new code you're running
(except if the exceptional code path is very short - like an early error return which lets you unindent the rest of the function)
pkg/cli/zip.go, line 338 at r1 (raw file):
NodeId: id, Type: serverpb.FileType_LOG, ListOnly: true,
why do we list only to download all of them after? If you're concerned about total file size, comment on that.
pkg/cli/zip.go, line 342 at r1 (raw file):
}); err != nil { if err := z.createError(prefix+"/logs", err); err != nil { return err
extracting all this code into a separate method will hopefully let you avoid this need to indent once more after every error check...
pkg/server/status.go, line 626 at r1 (raw file):
case serverpb.FileType_HEAP: // Requesting for saved Heap Profiles. dir = filepath.Join(s.admin.server.cfg.HeapProfileDirName, heapDir) case serverpb.FileType_LOG: // Requesting for saved Heap Profiles.
wrong comment
pkg/server/status_test.go, line 195 at r1 (raw file):
defer leaktest.AfterTest(t)() if log.V(3) {
what's this about? Sounds funky; can we make the test robust enough for higher levels?
pkg/server/serverpb/status.proto, line 304 at r1 (raw file):
// Represents the type of file. enum FileType {
trailing space
pkg/util/log/file.go, line 293 at r1 (raw file):
} // GetLogDir returns the log directory
what error can this return?
If it's never supposed to happen, consider asserting on it and not returning it.
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)
Ridwan Sharif seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Use the
GetFiles
endpoint instead for logfile collectioninstead of using the current enpoint that serves logs in the
form of entries. This method is more intuitive with what the
zip client actually wants to do.
For backwards compatibility reasons, the old method must still
be supported.
Release note: None