Skip to content

chore(controllers): Use req.NamespacedName directly #2025

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

Merged
merged 1 commit into from
May 26, 2025

Conversation

Baarsgaard
Copy link
Collaborator

@Baarsgaard Baarsgaard commented May 24, 2025

This removes all the places we store a pointer to the scheme unnecessarily and refactors the controllers to use the req.NamespacedName when fetching the resource in the beginning of all Reconcile functions.

@github-actions github-actions bot added the chore label May 24, 2025
@Baarsgaard Baarsgaard changed the title chore(controllers): Reduce Scheme usage and use NamespacedName from request directly chore(controllers): Reduce presence of Scheme and use req.NamespacedName directly May 24, 2025
@Baarsgaard Baarsgaard marked this pull request as ready for review May 24, 2025 21:15
Copy link
Collaborator

@weisdd weisdd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not like I perfectly know the internals, but, to me, the change around removal of the scheme does not look right. Even though it's the same across resources, it still needs to be properly propagated from the same instance: scheme = runtime.NewScheme() -> .AddToScheme calls in init() -> Reconcilers.

Here, the Scheme() gets inherited from Client interface, where it's defined as Scheme() *runtime.Scheme meaning it does not appear to be set to the real scheme where all our custom APIs are registered.

And having Scheme *runtime.Scheme as part of any reconciler definition is a common pattern anyway.

So, without extra comments from your side explaining why you think the change is safe, I feel like the change should not be made.

@Baarsgaard
Copy link
Collaborator Author

Baarsgaard commented May 25, 2025

I went digging through the implementation of the Manager struct to triple-check this.

We init the scheme exactly as you wrote above, but we never instantiate an API client.
Instead we rely on the Scheme in managerOptions

grafana-operator/main.go

Lines 185 to 189 in 129224e

mgrOptions := ctrl.Options{
Scheme: scheme,
Metrics: metricsserver.Options{BindAddress: metricsAddr},
WebhookServer: webhook.NewServer(webhook.Options{Port: 9443}),
HealthProbeBindAddress: probeAddr,

mgr is created by calling NewManager() with restConfig and mgrOptions which create the it cluster.Cluster.

grafana-operator/main.go

Lines 259 to 263 in 129224e

mgr, err := ctrl.NewManager(restConfig, mgrOptions)
if err != nil {
setupLog.Error(err, "unable to create new manager")
os.Exit(1) //nolint
}

The NewManager function is an alias of Manager.New
https://github.com/kubernetes-sigs/controller-runtime/blob/71f7db556ca57ce7ea6563f77d739f0d2a54233a/alias.go#L114

We see manager.New instantiating the internal cluster:
https://github.com/kubernetes-sigs/controller-runtime/blob/71f7db556ca57ce7ea6563f77d739f0d2a54233a/pkg/manager/manager.go#L328-L340

Cluster.New creating a client from the original mgrOptions.
https://github.com/kubernetes-sigs/controller-runtime/blob/71f7db556ca57ce7ea6563f77d739f0d2a54233a/pkg/cluster/cluster.go#L192-L226

Which define the GetClient and GetScheme functions
https://github.com/kubernetes-sigs/controller-runtime/blob/71f7db556ca57ce7ea6563f77d739f0d2a54233a/pkg/manager/internal.go#L234-L248

Used in our main.go to build and register the controllers:

grafana-operator/main.go

Lines 265 to 274 in 129224e

// Register controllers
if err = (&controllers.GrafanaReconciler{
Client: mgr.GetClient(),
Scheme: mgr.GetScheme(),
IsOpenShift: isOpenShift,
ClusterDomain: clusterDomain,
}).SetupWithManager(mgr); err != nil {
setupLog.Error(err, "unable to create controller", "controller", "Grafana")
os.Exit(1)
}

TLDR:
We instantiate a mgr struct with an options struct containing the built scheme.
During that instantiation, multiple API clients are built using the restConfig and Scheme which we then use to build our controllers.
Using client.GetScheme() returns the original scheme from the mgrOptions as the clients were instantiated with that Scheme originally.

@Baarsgaard
Copy link
Collaborator Author

Baarsgaard commented May 25, 2025

The above comment does not address whether this is a good change.
It hides the proliferation of Scheme which may not be ideal.

I'm not against dropping the commit with the Scheme changes if we decide it's not worth it.

@Baarsgaard Baarsgaard force-pushed the chore_cleanup_controllers branch from 9e5a251 to 6567be0 Compare May 25, 2025 14:51
@weisdd
Copy link
Collaborator

weisdd commented May 25, 2025

Thanks for the explanation!

Personally, I would rather favour leaving the existing code around Schema as it matches things described in the kubebuilder book, operator-sdk scaffolding, and other places. If other maintainers think the change should be accepted, I'm OK with that, so let's just wait for others to vote on this :)

@theSuess
Copy link
Collaborator

We talked about this in the weekly call and decided to keep the scheme. The NamespacedName stuff is good to merge though

@Baarsgaard
Copy link
Collaborator Author

Sounds good, I'll drop the commit later today.

@Baarsgaard Baarsgaard force-pushed the chore_cleanup_controllers branch from 6567be0 to 368acbf Compare May 26, 2025 17:58
@Baarsgaard Baarsgaard changed the title chore(controllers): Reduce presence of Scheme and use req.NamespacedName directly chore(controllers): Use req.NamespacedName directly May 26, 2025
@Baarsgaard Baarsgaard requested a review from weisdd May 26, 2025 18:06
@weisdd weisdd added this pull request to the merge queue May 26, 2025
Merged via the queue into master with commit b853b96 May 26, 2025
18 checks passed
@weisdd weisdd deleted the chore_cleanup_controllers branch May 26, 2025 20:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants