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

When client is configured to suppress API server warnings, warnings are still logged #2886

Closed
dlipovetsky opened this issue Jul 23, 2024 · 3 comments · Fixed by #2887
Closed
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@dlipovetsky
Copy link
Contributor

In #1468, we added a client option to surface API server warnings. In fact, this PR made warnings surface by default.

Even though we wanted to surface warnings, we exposed this behavior using the SuppressWarnings option. By default, the option is disabled, and warnings are surfaced.

However, when the option is enabled, warnings are not suppressed. This is because client-go continues to log warnings using its default warning handler. This was probably not caught when the PR was reviewd, because at the time of the PR, client-go apparently suppressed warnings by default. Today, client-go does not suppress warnings by default.


Let's elicit a warning from the API server. I'll use the client to create a Custom Resource, and include an undefined field in the request. I won't enable strict field validation, so the API server will return a warning.

If suppression is disabled, stderr shows:

2024-07-23T15:47:09-07:00	INFO	KubeAPIWarningLogger	metadata.finalizers: "example": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers

If suppression is enabled, stderr shows:

W0723 15:47:16.022148 1030480 warnings.go:70] metadata.finalizers: "example": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers

I expect the warning not to show. However, it does show, because client-go's default warning handler runs.

@dlipovetsky
Copy link
Contributor Author

/kind bug

@k8s-ci-robot k8s-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jul 23, 2024
@sbueringer
Copy link
Member

Definitely sounds like a bug

@dlipovetsky
Copy link
Contributor Author

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants