-
Notifications
You must be signed in to change notification settings - Fork 53
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
Actually init logging using Zap #267
Conversation
Hi @tchap. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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-sigs/prow repository. |
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Thanks for driving this! Can you add a bit more context on the motivation to move to zap? Maybe there are obvious reasons. I just don't have the context.
Can you elaborate on the "issue"? We definitely need to fix the issue to move forward.
The "after" doesn't have the go file and line numbers, which are important for debugging. |
I basically just wanted to get rid of the TODO logger init, so I went out to check what others are doing. Checked what
The flags being bound are just different: https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/log/zap#Options.BindFlags https://pkg.go.dev/k8s.io/klog/[email protected]#InitFlags I noticed that
Will check that out later today, thanks. |
Alright, added line numbers:
|
0bbc96a
to
b3ea552
Compare
@tchap please excuse our delay as we are preparing to release v0.1.0-rc1. |
If our goal is to remove the This is a bit of a personal opinion, but I don't love zap + controllerruntime logging, I've used it before and had issues with ergonomics. LMKWYT |
I tried using I don't really have a strong preference, I did use Zap in the past, but not really wrapped. The log format seems pretty readable for me. It's true the way it works with verbosity levels is not super elegant. Feel free to point me to a Logger implementation that would work better. I must say, though, that you never really use Zap in your executable code anyway. You just get a |
/lgtm Thanks for the help! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kfswain, tchap 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 |
Controllers typically use Zap these days. The only potential issue is that the flags are not compatible. This is somehow mitigated by supporting -v explicitly.
/lgtm |
Controllers typically use Zap these days. The only potential issue is that the flags are not compatible. This is somehow mitigated by supporting -v explicitly.
This is bit of an optimistic attempt of mine to push Zap through
since controllers typically use Zap these days AFAIK.
Feel free to push back since there is a potential issue with the flags not being compatible.
This is somehow mitigated by supporting
-v
manually.Related to #251
You can compare the output before vs after: