operator-framework / operator-framework/java-operator-sdk

Simple core and layered reconciler implementation for v6

未关闭
#3,563 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 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 Cleaner interface
  • Managed workflows inside the controller
  • Automatic generation filtering
  • Catching error and error handling, thus updateErrorStatus method.

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:

  1. The core will just work on top of a simplified Reconciler interface. What will handle basically be the all event mode. So we won't support finalizers, UpdateControl.patch methods ,and most of the functionality of ReconciliationDispatcher would be moved to an abstract Reconciler implementation: GenericReconciler.
  2. Retry, Rate limiting would stay as it is now
  3. 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

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

阅读当前 Reconciler 和 ReconciliationDispatcher 的职责,包括 updateErrorStatus,然后为提议的 GenericReconciler 和 WorkflowReconciler 层制作原型。完成的标准是有一个可运行的原型,以及一份恰当的设计说明,解释核心拆分并让现有用户的迁移保持简单。

由索引模型根据 Issue 内容生成。

评估

技术栈
java, kubernetes
领域
backend-api-design
Issue 类型
重构
难度
5/5
预计耗时
一周以上
活跃度
冷清
描述清晰度
需要澄清
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。