-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Provide an option in the clusterctl library to suppress API server warnings #10932
Comments
/area clusterctl |
Some implementation notes for later: We instantiate the default Proxy implementation in
We have a chance to pass some options at this time. However, we also instantiate the default Proxy implementation in
And we don't currently pass accept options here. We don't even use the InjectProxy pattern we established in the client package. |
I didn't look into implementation details, but agree with the goal /triage accepted |
@dlipovetsky You saw this only during clusterctl move until now? |
Okay also saw it in controller logs. Not sure if I like it :) |
@dlipovetsky Do you know if there are any discussions about rolling back this warning? It will be very very nosiy everywhere and almost everyone won't be able to just change the name of the finalizer (i.e. they can't do anything about it, for years usually, I think) |
That's a great question. I'll look around and report back. Started a thread: https://kubernetes.slack.com/archives/C0EG7JC6T/p1721923881095799 |
@dlipovetsky Will definitely review your PR in controller-runtime tomorrow, so that we get the ability to suppress warnings ASAP |
It turned out that controller-runtime, when configured to suppress warnings, was not doing so. That's now fixed, and should be in the next controller-runtime release. |
I realize that opinions can reasonably differ on whether to suppress warnings, or even which warnings to suppress. Today, controller-runtime is not that flexible; it can either suppress, or surface warnings. |
Yeah not sure what exactly to do, making it configurable in general in the clusterctl library is definitely okay (TBD how exactly)
We can make this configurable in the library with your follow-up PR in CR, right? |
Yes. I just filed kubernetes-sigs/controller-runtime#2896. With this change, clusterctl itself can define config.WarningHandler, or, for more flexibility, allow the clusterctl user to define it. |
@dlipovetsky Thx for opening the CR PRs. Now that they are merged, how do you want to handle this in clusterctl? I think the final implementation will be only availalbe in CR v0.19.x (which is too late for CAPI v1.8.x). Do you need something for CAPI v1.8.x? (if yes, we could go with providing an option to surpress all warnings with CAPI v1.8 and then something more fine-granular with 1.9) |
Third-party code creates a clusterctl client in two ways. The default client implementation includes a "proxy" implementation. The proxy is what configures the controller-runtime client, which is exclusively used to talk to the Kubernetes API. flowchart TD
user["third-party code"]
ccn["`cmd/clusterclient/client/cluster/New()`"]
gog["`cmd/clusterclient/client/cluster/GetOwnerGraph()`"]
np["`cmd/clusterclient/client/cluster/newProxy()`"]
nc["`cmd/clusterclient/client/cluster/proxy.NewClient()`"]
lib["`/cmd/clusterclient/client/*`"]
user --> ccn
user --> gog
ccn --> np
gog --> np
lib --> nc
We want third-party code to configure the controller-runtime client, specifically how to handle warnings returned by the Kubernetes API. The controller-runtime client de-duplicates and surfaces warnings by default. To customize handling, users must implement a rest.WarningHandler. I think a scalable solution is for clusterctl to implement a rest.WarningHandler. The handler should be configurable. e.g. users may want to suppress some warnings, like those about finalizers, while surfacing others. We should give the user the opportunity to configure the warning handler when they call |
Sounds good to me. So I assume something for capi 1.9 is early enough for you? (as the CR version used in 1.8.x doesn't allow this) Feedback from @fabriziopandini would be also good once he's back from PTO |
We're suppressing warnings using a very small patch in our downstream fork, and we can carry that patch until the first 1.9 upstream release. However, if there is enough community demand, I could work on a temporary upstream solution for 1.8.x. |
+1 to enable an option for 1.9.x (as a feature addition). |
@dlipovetsky If you want, we now should be ready to implement something for v1.9 on main |
/help |
@sbueringer: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed 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. |
/assign |
What would you like to be added (User Story)?
As an developer, I want to suppress API server warnings when I use the clusterctl library.
Detailed Description
As an developer, I want to suppress API server warnings when I use the clusterctl library.
More precisely, I want to suppress warnings when I create the clusterctl client here:
cluster-api/cmd/clusterctl/client/cluster/client.go
Lines 187 to 189 in 85d2880
So that, whenever clusterctl creates a "proxy" client, that client is configured to suppress API server warnings.
Clusterctl creates Kubernetes clients in at least 3 places, and it probably makes sense to suppress warnings in all of them.
cluster-api/cmd/clusterctl/client/cluster/proxy.go
Line 170 in d6afeb8
cluster-api/cmd/clusterctl/client/cluster/proxy.go
Line 195 in d6afeb8
cluster-api/cmd/clusterctl/client/cluster/proxy.go
Line 407 in d6afeb8
Anything else you would like to add?
Warnings can appear due to factors outside of my users' control. For example, as of Kubernetes v1.29.0 and newer, users begin seeing new warnings related to finalizer names during every "move" operation. Those warnings will continue to appear until all projects in the Cluster API have finalizers that conform to requirements (see #10914).
clusterctl move output with warnings
As a developer, if I choose to suppress warnings, I take responsibility for acknowledging, and addressing them, as needed.
We may also consider providing this option in the clusterctl CLI, but I think that's a separate topic.
Label(s) to be applied
/kind feature
The text was updated successfully, but these errors were encountered: