[Improvement]: Decouple DBInstance controller from concrete Harvester client implementation

[Yohansenanayake]

Area

Operators

Current Limitation

The DBaaS DBInstanceReconciler currently depends on the concrete Harvester client implementation through *harvester.Client.

The controller does not construct KubeVirt, CDI, Secret, Service, Endpoints, or ServiceMonitor resources directly, but it is still tied to the current dynamic-client implementation type.

This makes the future migration from dynamic Kubernetes client calls to typed Harvester/KubeVirt/CDI clients harder than necessary. It also makes controller unit tests depend on the concrete Harvester client rather than a narrow contract for the operations the reconciler actually needs.

Harvester remains the committed infrastructure backend for DBaaS. This improvement is not intended to abstract the operator away from Harvester or support another hypervisor. The goal is only to decouple reconciliation logic from the client implementation style used to access Harvester APIs.

Suggested Improvement

Introduce a Harvester-owned controller-facing interface for the operations used by the reconciler, then make the existing dynamic client implementation satisfy that interface.

Stage 1 should be a safe in-place change:

• Add a temporary harvester.Interface contract in internal/harvester; “temporary” means the interface name may later be renamed once we choose final names for the interface and concrete dynamic-client implementation.
• Change DBInstanceReconciler.Harvester from *harvester.Client to harvester.Interface.
• Change the readiness probe hook to accept harvester.Interface.
• Do not include unused methods such as GetSecret in the interface.
• Add a compile-time assertion that *harvester.Client implements harvester.Interface.
• Keep the implementation in-place; do not split dynamic and typed clients into subpackages yet.

This prepares the codebase for a future harvester.TypedClient implementation while keeping the current dynamic client as the default behavior.

Naming feedback is welcome before we make the interface name permanent. For Stage 1, the proposal uses harvester.Interface only to avoid renaming the existing concrete harvester.Client in the same change. In a later cleanup, we should choose final names for:

• the controller-facing Harvester interface
• the current dynamic-client implementation
• the future typed-client implementation

One possible final naming scheme is:

• harvester.Client for the interface
• harvester.DynamicClient for the current dynamic implementation
• harvester.TypedClient for the future typed implementation