operator-framework / operator-framework/java-operator-sdk
Simple core and layered reconciler implementation for v6
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 944
- Forks
- 242
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 43
Description
TL;DR We could make the core of the framework simpler by introducing a more layered architecture. While keeping the migration for the users trivial.
Problem definition
Currently the core of a framework has baked logic to work with higher level logic like:
- Adding finalizers by implementing
Cleanerinterface - Managed workflows inside the controller
- Automatic generation filtering
- Catching error and error handling, thus
updateErrorStatusmethod.
We recently added a generic mode Trigger reconciliation on all events
While it makes a nice API for the users, an maybe even nice out of the box experience, makes the core of the framework more complex - and even for users I assume hard to follow, if some wants to read the code.
What we could do in next major version is to layer those functionalities:
- The core will just work on top of a simplified
Reconcilerinterface. What will handle basically be the all event mode. So we won't support finalizers,UpdateControl.patch methods,and most of the functionality ofReconciliationDispatcherwould be moved to an abstract Reconciler implementation:GenericReconciler. - Retry, Rate limiting would stay as it is now
- The managed workflow handling would an additional extension of
GenericReconciler:WorkflowReconciler. That will handle the managed workflow discovery, their configuration etc.
Migration
Note that migration for the users could be kept trivial, basically just extending the GenericReconciler / WorkflowReconciler (Where we could support the UpdateControl etc as is now) instead of implementing Reconciler.
Pros
- The core would be much simpler
- The logic around these extended reconcilers much easier to be followed by the users (from source code)
Cons
- This does not provide direct value for users, other than easier to handle
Notes
- before we make a decision, we should explore this first in a proptotype
- TODO: proper design description
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the current Reconciler and ReconciliationDispatcher responsibilities, including updateErrorStatus, then prototype the proposed GenericReconciler and WorkflowReconciler layers. Done means a working prototype and a proper design description that explains the core split and keeps migration for existing users trivial.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, kubernetes
- Domain
- backend-api-design
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100