-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
🐛 Suppress API server warnings in the client #2887
🐛 Suppress API server warnings in the client #2887
Conversation
Skipping CI for Draft Pull Request. |
/test all I want to demonstrate that one of the new tests fails, as expected. |
9f18c25
to
16d25f1
Compare
}, | ||
) | ||
// By default, we de-duplicate and surface warnings. | ||
config.WarningHandler = log.NewKubeAPIWarningLogger( |
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.
WDYT about keeping config.WarningHandler if it is not nil?
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.
Good question. I considered this, and actually prefer it.
I thought it might be seen as a backward-incompatible change, so I did not include it in this PR.
However, thinking about it now, I realize that, by default, config.WarningHandler is nil. So, in the default case, we would continue to modify warning handler, but we would also respect the warning handler the user chose.
The downside is that, in some cases. we respect config.WarningHandler
, but ignore options.WarningHandler
. For example, if the user says:
config.WarningHandler = rest.NoWarnings{}
options.WarningHandler = WarningHandlerOptions{SuppressWarnings: false}
Then we will suppress warnings, even though the user appears to ask us to surface warnings.
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.
On a related note, I thought it might be easier to remove options.WarningHandler
altogether, and ask the user to define config.WarningHandler
. However, removing that might annoy users.
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.
The more I think about that, the more I like it. How about: If you define config.WarningHandler
, we'll respect it. If you don't , we'll use KubeAPIWarningLogger
configured some default way.
If you don't like its default configuration, you can always choose to instantiate KubeAPIWarningLogger
with a custom configuration, and yourself, and assign it to config.WarningHandler
.
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 the same approach we take with user agent. That is, we respect the user's configuration, or we use a value that we choose:
controller-runtime/pkg/client/client.go
Lines 123 to 125 in 16d25f1
if config.UserAgent == "" { | |
config.UserAgent = rest.DefaultKubernetesUserAgent() | |
} |
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.
My main goal is to be able to configure a custom warning handler. E.g. for Cluster API it could be useful to only drop certain warnings (the finalizer one, in controllers).
I'm not entirely sure if we should deprecate the WarningHandler field or not
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.
We could also allow folks to configure a WarningHandler in the WarningHandlerOptions (that has a higher priority than the other two fields)
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.
Guess this depends overall if we think we should:
- just find a way that user can configure a WarningHandler
- also respect what we get from the rest config
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 #2887 (comment) I demonstrated that we cannot meet both goals at the same time.
Working from the "principle of least suprise," I think it's better to deprecate WarningHandlerOptions, and ask the user to use the rest config.
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.
Fine for me! Let's see what others say on the new PR
I agree with
Let's address the nit here (#2887 (comment)) then we can look for a more complete solution in the next PR @alvaroaleman @vincepri WDYT? |
Always delete test namespace.
/lgtm |
LGTM label has been added. Git tree hash: e100f449b2494aed104fc0e316ef991e05d426a7
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlipovetsky, sbueringer 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 |
/cherry-pick release-0.18 |
@sbueringer: once the present PR merges, I will cherry-pick it on top of release-0.18 in a new PR and assign it to you. 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-sigs/prow repository. |
@sbueringer: new pull request created: #2890 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-sigs/prow repository. |
Thanks a lot for backporting! |
This adds:
Test failure
Fixes #2886