Skip to content
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

Merged
merged 4 commits into from
Jul 29, 2024

Conversation

dlipovetsky
Copy link
Contributor

@dlipovetsky dlipovetsky commented Jul 23, 2024

This adds:

  • Tests that verify warning suppression in the client. Note that one of the test fails, confirming the bug. These tests are meant to help us validate the fix, and avoid future regression.
  • Ensures, by configuring the warning handler in client-go, that API server warnings are in fact suppressed.
Test failure
> Enter [BeforeEach] Client - /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:153 @ 07/24/24 03:22:08.098
< Exit [BeforeEach] Client - /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:153 @ 07/24/24 03:22:08.098 (0s)
> Enter [It] should not log warnings when warning suppression is enabled - /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:273 @ 07/24/24 03:22:08.098
2024-07-24T03:22:08Z	INFO	klog	unknown field "spec"
2024-07-24T03:22:08Z	INFO	klog	unknown field "status"
[FAILED] expected to find zero API server warnings in the client log
In [It] at: /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:312 @ 07/24/24 03:22:08.127
< Exit [It] should not log warnings when warning suppression is enabled - /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:273 @ 07/24/24 03:22:08.127 (29ms)
> Enter [AfterEach] Client - /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:210 @ 07/24/24 03:22:08.127
< Exit [AfterEach] Client - /home/prow/go/src/sigs.k8s.io/controller-runtime/pkg/client/client_test.go:210 @ 07/24/24 03:22:08.138 (11ms)

Fixes #2886

@k8s-ci-robot
Copy link
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Jul 23, 2024
@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 23, 2024
@dlipovetsky
Copy link
Contributor Author

dlipovetsky commented Jul 24, 2024

/test all

I want to demonstrate that one of the new tests fails, as expected.

Please see https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_controller-runtime/2887/pull-controller-runtime-test/1815949340502396928

@dlipovetsky dlipovetsky changed the title 🐛 Tests to verify warning suppression in the client 🐛 Suppress API server warnings in the client Jul 24, 2024
@dlipovetsky dlipovetsky marked this pull request as ready for review July 24, 2024 04:13
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 24, 2024
@k8s-ci-robot k8s-ci-robot requested a review from inteon July 24, 2024 04:13
@dlipovetsky dlipovetsky force-pushed the fix-warning-handler branch from 9f18c25 to 16d25f1 Compare July 24, 2024 04:17
},
)
// By default, we de-duplicate and surface warnings.
config.WarningHandler = log.NewKubeAPIWarningLogger(
Copy link
Member

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?

Copy link
Contributor Author

@dlipovetsky dlipovetsky Jul 25, 2024

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.

Copy link
Contributor Author

@dlipovetsky dlipovetsky Jul 25, 2024

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@dlipovetsky dlipovetsky Jul 25, 2024

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:

if config.UserAgent == "" {
config.UserAgent = rest.DefaultKubernetesUserAgent()
}

Copy link
Member

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

Copy link
Member

@sbueringer sbueringer Jul 26, 2024

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)

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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

@alvaroaleman alvaroaleman added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label Jul 26, 2024
@sbueringer
Copy link
Member

@dlipovetsky

I agree with

I think we can merge this PR, because it preserves existing behavior (which does not respect config.WarningHandler by default).

Let's address the nit here (#2887 (comment)) then we can look for a more complete solution in the next PR

@alvaroaleman @vincepri WDYT?

@sbueringer
Copy link
Member

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 29, 2024
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: e100f449b2494aed104fc0e316ef991e05d426a7

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 29, 2024
@sbueringer
Copy link
Member

/cherry-pick release-0.18

@k8s-infra-cherrypick-robot

@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:

/cherry-pick release-0.18

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.

@k8s-ci-robot k8s-ci-robot merged commit 89bb86e into kubernetes-sigs:main Jul 29, 2024
9 checks passed
@k8s-infra-cherrypick-robot

@sbueringer: new pull request created: #2890

In response to this:

/cherry-pick release-0.18

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.

@dlipovetsky
Copy link
Contributor Author

Thanks a lot for backporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When client is configured to suppress API server warnings, warnings are still logged
5 participants