Migrating the current reconciler

[roy01ajit]

What should be the most efficient way to migrate the current reconciler to this one?
Should we approach the manual way or any code-gen tool can help?

[scothis]

This is a good question.

First, as a library that sits on top of controller-runtime, you have full access to controller-runtime types and capabilities. This makes it possible to migrate incrementally. Adopt as much (or little) as makes sense for your needs. It's perfectly normal to leave a reconciler or webhook in pure controller-runtime types if r-r doesn't provide a paved path that matches where you want to go.

The best place to start when migrating is with a good test suite for your controller, this way you can have confidence that the refactoring isn't introducing new unintended behavior. The test support in reconciler-runtime is my personal favorite feature. You can use ReconcilerTests directly with an existing reconciler, keeping the use of reconciler-runtime limited to the test suite.

Once you feel there is sufficient test coverage to have confidence in the next steps, we can start to migrate the reconciler. The ResourceReconciler is the most common reconciler used. It implements the controller-runtime Reconciler interface and acts as the primary bridge from controller-runtime into reconciler-runtime. It will handle a lot of the boiler plate code you typically have to write to setup an informer, configuring logr, loading the resource being reconciled and updating its status if needed. The main business logic for the controller is delegated to a SubReconciler. This is where you start to have a lot of choice and more powerful/nuanced behavior. But it's best to start simple. The most general SubReconciler is the SyncReconciler. It has two method you can implement, a Sync which is called during the normal life of the resource, and the Finalize method which is called when the resource is terminating (deleted with a finalizer).

Combining the ResourceReconciler and SyncReconciler together, a controller for a hypothetical foov1.Bar resource would look like:

// existing controller-runtime code in your main
ctx := ctrl.SetupSignalHandler()
mgr := ... // the controller-runtime Manager

resyncPeriod := 10 * time.Hour // duration interval that controller-runtime controller will reprocess each resource
config := reconcilers.NewConfig(mgr, &foov1.Bar{}, resyncPeriod)

// new reconciler-runtime behavior, typically loaded from your "controllers" package
r := &reconcilers.ResourceReconciler[*foov1.Bar]{
	Reconciler: &reconcilers.SyncReconciler[*foov1.Bar]{
		Sync: func(ctx context.Context, resource *foov1.Bar) error {
			// TODO add business logic
			return nil
		},
	},

	Config: config,
}

// new reconciler-runtime code, typically in your main
if err := r.SetupWithManager(ctx, mgr); err != nil {
	setupLog.Error(err, "unable to create controller", "controller", "Bar")
	os.Exit(1)
}

// existing controller-runtime code in your main
setupLog.Info("starting manager")
if err := mgr.Start(ctx); err != nil {
	setupLog.Error(err, "problem running manager")
	os.Exit(1)
}

This example is attempting to streamline existing code that will be scaffolded for you with by a tool like kubebuilder with the new reconciler-runtime bits. Keeping architectural separation into multiple packages is strongly encouraged, but skipped here.

Once you have your controller logic working inside the SyncReconciler, you can start to explore more advanced SubReconcilers that can decompose the single reconciler its logical steps. For example, Sequence executes a series of SubReconcilers in order, ChildReconciler manages the lifecycle of a child resource, WithFinalizer sets and clears a finalizer so you can safely create and cleanup external state in the nested SubReconciler. If you need behavior that doesn't exist in reconciler-runtime today, you can always use a SyncReconciler as a generic escape hatch, or even implement your own type that implements the SubReconciler interface.

As you decompose your reconciler into a set of SubReconcilers, you can also start to test each SubReconciler in isolation using SubReconcilerTests. The scope is very similar to the ReconcilerTests, but targeting the SubReconciler interface instead of the Reconciler interface. Testing error conditions becomes much easier when you can isolate where the error originates.

Hope that helps.

[roy01ajit]

Thanks for the detailed and logical explanation.
It does give me an idea of what to try and how to proceed.
Excellent answer :)
Will reach out again if any doubt