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
⚠️ Bump github.com/go-logr/zapr & github.com/go-logr/logr to v1.1.0 #1593
Conversation
Welcome @morlay! |
Hi @morlay. 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/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: morlay The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/ok-to-test |
/milestone v0.10.x |
/retitle |
730ad94
to
3dfe5be
Compare
There might be some impact on this change with respect to the zap-log-level and zap-stacktrace-level flags because negative V values are now treated the same as The zap For example, this test may fail with the change to logr/zapr v1.0.0: controller-runtime/pkg/log/zap/zap_test.go Lines 538 to 539 in 40cffdc
|
Block by |
Moving this to a future milestone. The kubernetes/kubernetes project is still on logr 0.4.0 for the 1.22 release, so controller-runtime will stay on 0.4.0 for v0.10.x to stay aligned with upstream. /milestone Next |
The absence of this merge blocking is upgrading some other components. 🙏 |
Requesting to prioritize this issue. Thank you!!! |
We should probably merge this in, but is there going to be some downstream impact for consumers, in which case this should go to v0.11? |
Yes to v0.11 |
- `k8s.io/*` bundle to `v0.22.2` - `github.com/golang/mock` to `v1.6.0` (is not compiled into final binary but checked by dependabot) - `github.com/miekg/dns` to `v1.1.43` The latest `sigs.k8s.io/external-dns` is problematic in terms it uses latest `github.com/go-logr/logr` which is incompatible with previous versions. This causes issues in `controller-runtime` and will require code changes on our side (another PR). [This PR](kubernetes-sigs/controller-runtime#1593 (comment)) would be unblock - github.com/go-logr/logr - sigs.k8s.io/external-dns
- `k8s.io/*` bundle to `v0.22.2` - `github.com/golang/mock` to `v1.6.0` (is not compiled into final binary but checked by dependabot) - `github.com/miekg/dns` to `v1.1.43` The latest `sigs.k8s.io/external-dns` is problematic in terms it uses latest `github.com/go-logr/logr` which is incompatible with previous versions. This causes issues in `controller-runtime` and will require code changes on our side (another PR). [This PR](kubernetes-sigs/controller-runtime#1593 (comment)) would be unblock - github.com/go-logr/logr - sigs.k8s.io/external-dns Signed-off-by: kuritka <kuritka@gmail.com>
- `k8s.io/*` bundle to `v0.22.2` (controller-gen tool makes changes in CRD description after bump) - `github.com/golang/mock` to `v1.6.0` (is not compiled into final binary but checked by dependabot) - `github.com/miekg/dns` to `v1.1.43` - `github.com/infobloxopen/infoblox-go-client` to `v1.1.1` (changes argument CreateTXTRecord from integer to uint) The latest `sigs.k8s.io/external-dns` is problematic in terms it uses latest `github.com/go-logr/logr` which is incompatible with previous versions. This causes issues in `controller-runtime` and will require code changes on our side (another PR). [This PR](kubernetes-sigs/controller-runtime#1593 (comment)) would be unblock - github.com/go-logr/logr - sigs.k8s.io/external-dns Signed-off-by: kuritka <kuritka@gmail.com>
- `k8s.io/*` bundle to `v0.22.2` (controller-gen tool makes changes in CRD description after bump) - `github.com/golang/mock` to `v1.6.0` (is not compiled into final binary but checked by dependabot) - `github.com/miekg/dns` to `v1.1.43` - `github.com/infobloxopen/infoblox-go-client` to `v1.1.1` (changes argument CreateTXTRecord from integer to uint) The latest `sigs.k8s.io/external-dns` is problematic in terms it uses latest `github.com/go-logr/logr` which is incompatible with previous versions. This causes issues in `controller-runtime` and will require code changes on our side (another PR). [This PR](kubernetes-sigs/controller-runtime#1593 (comment)) would be unblock - github.com/go-logr/logr - sigs.k8s.io/external-dns Signed-off-by: kuritka <kuritka@gmail.com>
related to #697 `k8s.io/*` bundle to `v0.22.2` (controller-gen tool makes changes in CRD description after bump) - `github.com/golang/mock` to `v1.6.0` (is not compiled into final binary but checked by dependabot) - `github.com/miekg/dns` to `v1.1.43` - `github.com/infobloxopen/infoblox-go-client` to `v1.1.1` (changes argument CreateTXTRecord from integer to uint) The latest `sigs.k8s.io/external-dns` is problematic in terms it uses latest `github.com/go-logr/logr` which is incompatible with previous versions. This causes issues in `controller-runtime` and will require code changes on our side (another PR). [This PR](kubernetes-sigs/controller-runtime#1593 (comment)) would be unblock - github.com/go-logr/logr - sigs.k8s.io/external-dns Signed-off-by: kuritka <kuritka@gmail.com>
related to #697 `k8s.io/*` bundle to `v0.22.2` (controller-gen tool makes changes in CRD description after bump) - `github.com/golang/mock` to `v1.6.0` (is not compiled into final binary but checked by dependabot) - `github.com/miekg/dns` to `v1.1.43` - `github.com/infobloxopen/infoblox-go-client` to `v1.1.1` (changes argument CreateTXTRecord from integer to uint) `sigs.k8s.io/controller-runtime` to `v0.10.2` The latest `sigs.k8s.io/external-dns` is problematic in terms it uses latest `github.com/go-logr/logr` which is incompatible with previous versions. This causes issues in `controller-runtime` and will require code changes on our side (another PR). [This PR](kubernetes-sigs/controller-runtime#1593 (comment)) would be unblock - github.com/go-logr/logr - sigs.k8s.io/external-dns Signed-off-by: kuritka <kuritka@gmail.com>
If we are going to cut a release with this breaking change + k8s 1.22 deps, can we merge this before #1709 ? |
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.
In the GoDoc for logr.Logger
, I see:
Implementations of LogSink should provide their own constructors that return Logger, not LogSink.
It seems like we're violating this guidance with the DelegatingLogSink
constructor.
I'm guessing the reason is that we somehow need to call Fulfill()
eventually, but we can't if our concrete DelegatingLogger
is lost behind the logr.Logger
abstraction.
Is there a way to overcome this? Perhaps we can fudge the guidance and have a NewDelegatingLogger
that returns a DelegatingLogger
rather than a logr.Logger
? And then callers could call Fulfill()
but then also unwrap it to get at an underlying logr.Logger
?
Maybe related, do we need DelegatingLogSink
to be exported? I wonder if we can restore DelegatingLogger
and unexport DelegatingLogSink
.
I'm totally spitballing here. Not sure what cascading effects this would cause.
@@ -535,9 +539,10 @@ var _ = Describe("Zap log level flag options setup", func() { | |||
logOut.Truncate(0) | |||
logger.V(4).Info("test 4") // Should not be logged | |||
Expect(logOut.String()).To(BeEmpty()) | |||
logger.V(-3).Info("test -3") // Log a panic, since V(-1*N) for all N > 0 is not permitted. | |||
Expect(logOut.String()).To(ContainSubstring(`"level":"dpanic"`)) | |||
logger.V(-3).Info("test -3") // Since logr v1.0.0, negative logr level will be force to 0 https://github.com/go-logr/logr/blob/master/logr.go#L269-L279、. |
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 is a runtime breaking change, so we need to make it very apparent in release notes what this means for users currently using negative V()
values.
logger.V(-3).Info("test -3") // Log a panic, since V(-1*N) for all N > 0 is not permitted. | ||
Expect(logOut.String()).To(ContainSubstring(`"level":"dpanic"`)) | ||
logger.V(-3).Info("test -3") // Since logr v1.0.0, negative logr level will be force to 0 https://github.com/go-logr/logr/blob/master/logr.go#L269-L279、. | ||
Expect(logOut.String()).To(ContainSubstring("test -3")) |
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.
Can we have the unit test try various negative numbers and have the expectations include a test for the level we expect them to come out as?
ad5bc6e
to
3079894
Compare
Have to return So I have upgrade codes, and make and added new For Log.GetSink().(canFulfill).Fulfill(l.GetSink()) or added a new function to safe fill func Fulfill(l *logr.Logger, logSink logr.LogSink) {
if canFulfill, ok := l.GetSink().(interface{ Fulfill(logSink logr.LogSink) }); ok {
canFulfill.Fulfill(logSink)
}
} |
@morlay: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
@morlay: PR needs rebase. 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. |
Sames previous version already meged. Close this |
Bump github.com/go-logr/zapr & github.com/go-logr/logr to v1.0.0
with logr apis refactor