operator-framework / operator-framework/java-operator-sdk
Simple core and layered reconciler implementation for v6
还没有人认领这个 Issue。
- 主要语言
- Java
- 星标
- 944
- 派生
- 242
- 平均合并
- 1 天 4 小时
- 30 天内合并 PR
- 43
描述
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
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
阅读当前 Reconciler 和 ReconciliationDispatcher 的职责,包括 updateErrorStatus,然后为提议的 GenericReconciler 和 WorkflowReconciler 层制作原型。完成的标准是有一个可运行的原型,以及一份恰当的设计说明,解释核心拆分并让现有用户的迁移保持简单。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- java, kubernetes
- 领域
- backend-api-design
- Issue 类型
- 重构
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 冷清
- 描述清晰度
- 需要澄清
- 新手友好度
- 25/100