Honor stderrthreshold when logtostderr is enabled#36730
Honor stderrthreshold when logtostderr is enabled#36730pierluigilenoci wants to merge 1 commit intokubernetes:masterfrom
Conversation
|
Hi @BenTheElder, @krzyzacy, @fejta — would you be willing to review? Thank you! |
|
Hey, @krzyzacy is emeritus these days, the CI will auto-assign current reviewers and auto-suggest a current approver for assigning after review. |
| klog.InitFlags(klogFlags) // Add the klog flags | ||
| // Opt into fixed stderrthreshold behavior (kubernetes/klog#212). | ||
| _ = klogFlags.Set("legacy_stderr_threshold_behavior", "false") | ||
| _ = klogFlags.Set("stderrthreshold", "INFO") |
There was a problem hiding this comment.
this seems ok but I don't think we're using any of this
There was a problem hiding this comment.
You're right — if triage/summarize isn't actively used, this has no practical impact. I already applied your URL nit in the previous push. Happy to close this if the code is effectively dead. What do you think?
| func setUpLogging(logtostderr bool, v int) { | ||
| klogFlags := flag.NewFlagSet("klog", flag.PanicOnError) | ||
| klog.InitFlags(klogFlags) // Add the klog flags | ||
| // Opt into fixed stderrthreshold behavior (kubernetes/klog#212). |
There was a problem hiding this comment.
nit can we use:
| // Opt into fixed stderrthreshold behavior (kubernetes/klog#212). | |
| // Opt into fixed stderrthreshold behavior (https://github.com/kubernetes/klog/issues/212). |
It's not much longer but you can probably click it in your editor or at least copy-paste to the browser more easily, and it will not generate backreference noise on the issue.
|
Hi @aojea, @upodroid — this PR adds one line to set Would you be able to review when you get a chance? Thank you! |
|
New changes are detected. LGTM label has been removed. |
|
Hi @BenTheElder — thanks for the feedback. I applied your URL nit suggestion in the latest push. Regarding your comment about the code not being actively used: would you still like this fix applied for correctness (in case the code is exercised in the future), or would you prefer to close this PR? Happy either way — just let me know. Thank you! |
|
Hi @BenTheElder — just a friendly follow-up on the open question. Looking at the codebase,
So the The change itself is small — it opts into the fixed Would you be willing to take another look? Thank you! |
klog v2 defaults -logtostderr to true, which silently ignores the -stderrthreshold flag — all log levels are unconditionally sent to stderr. Bump klog to v2.140.0 in triage/go.mod and opt into the fixed behavior by setting legacy_stderr_threshold_behavior=false and stderrthreshold=INFO. This preserves current output while letting users override via CLI flags. Ref: kubernetes/klog#212, kubernetes/klog#432 Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
ed86f5b to
381f252
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: krzyzacy, pierluigilenoci 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 |
What this PR does
Fixes the
-stderrthresholdflag so it is honored even when-logtostderr=true(the klog v2 default) in the triage/summarize tool.Problem
klog v2 defaults
-logtostderrtotrue. When this flag is active, the-stderrthresholdflag is silently ignored — all log messages (INFO, WARNING, ERROR, FATAL) are unconditionally written to stderr.This has been an open issue since 2020: kubernetes/klog#212.
Fix
PR kubernetes/klog#432 introduced the fix in klog v2.140.0. This PR:
triage/go.modlegacy_stderr_threshold_behavior=falseandstderrthreshold=INFOon theklogFlagsFlagSet insetUpLogging()Setting
stderrthreshold=INFOpreserves the current default behavior. Users can now override it on the command line and it will actually work.Changes
triage/summarize/summarize.go: AddklogFlags.Set()calls afterklog.InitFlags(klogFlags)triage/go.mod/triage/go.sum: Bumpk8s.io/klog/v2v2.10.0 → v2.140.0Ref: kubernetes/klog#212, kubernetes/klog#432