-
Notifications
You must be signed in to change notification settings - Fork 214
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
Allow klog configuration from somewhere other than flag #336
Comments
The problem with klog is that it is close to impossible to experiment with new APIs: as soon as they are in a release, the API has to adhere to the strict compatibility guarantee of a v2 Go module. Therefore I am not very enthusiastic about anything that will need such significant changes. |
I am thinking it would just involve adding a public method that updates the value of settings.verbosity, probably just by calling Level.set(). I am kind of new to k8s API compliance. Would a simple addition of a public API cause problems, even if no other methods are touched? |
We would be bound to support that API as-is forever (well, within klog/v2, but we don't want to switch to a /v3). The API therefore becomes technical debt. |
Ah understood. |
I understand the reluctance to make this change, but the lack of configurability creates situations that are very difficult to deal with. For example, I have an application that is dependent upon code in The lack of configurability here, even if it's a tech debt burden for the future, is fairly problematic on its own. Any application using code the logs via klog that does not itself use klog as its primary logger is going to have problems. Any application that wants to configure logging by any means other than the command-line at start is also going to have problems. |
No, you don't 😁 You can create a flag set that is not the one from your program and use that to change the values:
I understand that this is perhaps not the API that you want, but at least it exists and exposes all options in a consistent way. |
Here is one potential way forward:
@dims: would that be okay? |
@pohly works for me! |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
/remove-lifecycle rotten |
@pohly: Reopened this issue. In response to this:
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. |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/kind feature
Describe the solution you'd like
Currently, the main way that you can configure klog is through the registering of flags with the standard flag package. This is useful for most cases, but it would be useful to provide another configuration interface. My idea would be to provide something like
InitWithValues(init *klog.Configuration)
method where the config struct provides the same flag values, but through go instead.Or at the very least, provide an external method
SetVerbosity(in int)
as a means for configuring the verbosity in some way other than flags. This would be useful if you are using other flag libraries and allow you to configure klog with them as well and not being tied to using the standard flag library.Let me know what you think.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
The text was updated successfully, but these errors were encountered: