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
Update klog to 0.3.0 #76474
Update klog to 0.3.0 #76474
Conversation
90977ca
to
40290d8
Compare
@@ -105,6 +105,7 @@ func addGlogFlags(fs *pflag.FlagSet) { | |||
register(global, local, "log_backtrace_at") | |||
register(global, local, "log_dir") | |||
register(global, local, "log_file") | |||
register(global, local, "log_file_max_size") |
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.
is it our intent to keep adding global flags like this? I expected us to manage flags in a better way going forward, especially if we control the log library
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.
Honestly I'm not sure. I updated the code where the codebase is referenced, I can take this one out I think, but the other change in components-base is required otherwise some tests fail.
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.
To be clear, the issue is with the change made in klog, but this change here is a good example of the further pollution of the global flag space it is causing. Before we pull it into kubernetes, we should resolve the future direction of klog flag handling.
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.
cc @dims
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.
@liggitt please see kubernetes/klog#56 and kubernetes/klog#55 we can continue the conversation there
/retest |
861b6c4
to
2d63c92
Compare
Signed-off-by: Vince Prignano <vincepri@vmware.com>
2d63c92
to
3f55226
Compare
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, liggitt, vincepri 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 |
/hold cancel |
FYI it looks like this may have broken Kubelet's log to file behavior: #77416 @yujuhong mentioned it now writes to the log file up to the point where it tries to load the Kubelet config file, then starts logging to stderr afterwards. This makes me wonder if there is some nefarious interaction between how klog registers its flags and the way we currently enforce flag precedence. |
I think the issue is that this PR changes the global FlagSet construction logic to call klog.InitFlags every time a new FlagSet is constructed. This has the side effect of resetting the values of all klog flags to defaults. The old logic constructed a FlagSet that referenced the global flags without changing their values. Constructing the global flag set should not have such a side-effect, because the Kubelet currently needs to re-parse the full command line to enforce precedence while explicitly not calling Set for global flag values a second time, or else accumulator flags could end up with duplicate entries during the re-parse. |
// addKlogFlags adds flags from k8s.io/klog | ||
func addKlogFlags(fs *pflag.FlagSet) { | ||
local := flag.NewFlagSet(os.Args[0], flag.ExitOnError) | ||
klog.InitFlags(local) |
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 has the side effect of resetting the values in klog to defaults every time a new flagset is constructed.
@dims I believe the problem I described only happens in the Kubelet; I don't think any other components have copied the flag precedence approach in the Kubelet yet (hence the legacyflag work). That said, if other components wanted to do something similar, a similar call to InitFlags in the globalflag package in component-base will cause the same issue. I think we should be able to fix by just reverting the Kubelet code to register each klog flag individually, and avoid the side-effect. |
Alternatively, we could revert this PR, then fix klog so that InitFlags itself is free of global side-effects. |
Former fix: #77562 |
@vincepri FYI reverting the Kubelet code == registering each klog flag individually. The other one was "fix klog so that InitFlags itself is free of global side-effects." |
Signed-off-by: Vince Prignano vincepri@vmware.com
What type of PR is this?
What this PR does / why we need it:
This PR updates
klog
dependency to the latest release: 0.3.0.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: