k8s-ci-robot
commented
1 week ago This issue is currently awaiting triage.
If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
User Story
As a developer, I would like to use CAPI Operator provider controller phases to implement my own provider and allow granular lifecycle management.
Detailed Description
Existing CAPI Operator controller implementation is internal and private. While it makes sense to use providers as is, in some occasions there is a need to extend or replace individual parts of reconciliation loops, for different concerns, such as:
For that reason, I would like to request the effort to work on an external (public) API implementation to allow users to implement a custom operator provider. This would allow the CAPI operator controller usage as a framework.
Anything else you would like to add:
Examples of other project implementations of this feature:
Operators current external controller API is quite thin, and tailored to specific provider use: https://github.com/kubernetes-sigs/cluster-api-operator/blob/main/controller/alias.go
[Miscellaneous information that will assist in solving the issue.]
/kind feature