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
klog v2.60.1 #108725
klog v2.60.1 #108725
Conversation
@pohly: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
/retest |
/assign |
/hold Let's also include kubernetes/klog#306 and https://github.com/kubernetes/kubernetes/compare/master...pohly:klog-flush?expand=1 in this PR. |
// | ||
// This must be called during initialization before goroutines are started. | ||
func EnableContextualLogging(enabled bool) { | ||
contextualLoggingEnabled = enabled |
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.
This must be called during initialization before goroutines are started.
if there any enforcement or protection if someone doesn't follow this rule? the places we'll be calling this will require parsing feature gates from args/config files, which means we can't call this from func init()
methods which are easier to reason about goroutines not having started.
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.
This will get called in component-base/logs InitLogs which was recently (1.23) moved to the beginning of a program's startup:
https://github.com/kubernetes/component-base/blob/c5dae0cde26ef1c4fc6cfe6384bed8f36148f13f/cli/run.go#L122-L144
kubernetes/cmd/kubelet/app/server.go
Lines 226 to 232 in 637394c
// Config and flags parsed, now we can initialize logging. | |
logs.InitLogs() | |
logOption := &logs.Options{Config: kubeletConfig.Logging} | |
if err := logOption.ValidateAndApply(); err != nil { | |
klog.ErrorS(err, "Failed to initialize logging") | |
os.Exit(1) | |
} |
There's no enforcement to prevent data races or detect misuse. We could use an atomic Int32 access, but I don't think that this is needed. Even if it gets misused and the race goes wrong, the impact will probably be low.
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.
FWIW, the decision to not do locking also applies to SetLogger which has been around for much longer.
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 a while SetLogger used mutex locking, but the corresponding read accesses don't, which rendered the mutex a bit mute (no pun intended), for example in https://github.com/kubernetes/klog/blob/f8e668dbaa5f6f0e6a5c24ffd7667263840d79ae/klog.go#L1387.
I brought this up when I noticed it and @serathius explained that relying on sequential execution is good enough.
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.
non-threadsafe globally writeable package vars seems like an anti-pattern we wouldn't want to extend.
I'm really not trying to make this a proxy review of changes that have gone into klog, but I'm concerned that the library is becoming harder to use safely within k/k
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.
IMHO it's as easy (or hard) as before: some functions have to be called early. It's true that this PR adds one more of those, but it doesn't change how klog is used in k/k because EnableContextualLogging will be called at the same time or even earlier than the others (like SetLogger).
The new release supports FlushAndExit and contextual logging.
Not all code knows that it needs to flush through component-base/logs.FlushLogs when the JSON logger is used. By registering the flush callback together with the logger, klog.Flush and klog.FlushAndExit are sufficient for flushing all data.
The advantage is that klog properly handles restarting of the daemon with a new interval and the daemon can be stopped. Stopping the daemon solves a data race that the tests had when modifying the Logger's flush function while goroutines from previous tests were still running.
002d139
to
0b7d303
Compare
/remove-sig api-machinery |
/approve |
dependency mechanics lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, liggitt, pohly 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 |
/lgtm |
/hold cancel |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
The new release supports FlushAndExit and contextual logging.
Does this PR introduce a user-facing change?