kis-design issue

[elliott10]

• 调度模块与其他模块的通信方式该怎么来选用，例如网络断了等问题；（oto自动测试系统使用了rsync, ssh, adb）
• 获取更新微服务中，每次进行merge操作估计可能会遇到不少冲突，需要人工，为何不直接git pull仓库更新即可；（updateGIT.sh脚本是远程与本地HEAD commit对比，有则更新）
• git bisect　实际可能不太好操作，其中包括kernel commit树的杂乱；
• Linux Kernel的config文件该怎么选择。貌似LKP之前提供的一个基于debian发型版的默认config; lkp jobs有很多，以及是否需要新增额外的jobs呢？新增jobs也是一个较重要的工程；
• 当测试系统某个环境出现错误，如编译时错误，网络时错误，需要一个什么服务来截获并保持测试系统继续运行（keep alive service ?）

[chyyuu]

可以有一个监控程序监控整个的运行过程。 松耦合，逻辑上有总控，达到资源利用最大化。 硬件可以随时退出系统，对系统不会造成破坏。 生成的数据在本地，索引汇总在root node。

[Hoblovski]

20191012-KIS讨论

• 会涉及多机吗？会涉及多机，需要现在就考虑多机和网络；
• 测试：分析commit和version的测试是没有区别的；
• 自动运行：用PXE在一些情况下可能无法保存测试现场；
• 各任务的关系紧密程度：总控与各部分是松耦合；总控的角色也是很强的；
• 数据存放采用数据库，在本地保存，但会有索引的汇总；

讨论：

• 基本服务的能力描述：配置文件；
  • 测试：运行结果；监测参数；单机运行和多机运行；模拟器环境和真实机器环境；
  • 编译：在多种配置下进行编译，确认编译成功；
  • 代码合并：多人的代码修改合并成一个版本，确认合并成功；
  • 生成结果的分析：
• 信息交流的标准化；
• 代码git分支的合并错误分析：这是一个独立的问题；正确的程度：每个更新能与基础版本合并；所有的更新全都能合并到一起；
• 这个测试过程的动态优化：只跑最新的（旧的未完成任务可以删除）；出错才去分析导致错误的中间版本；

基本工作流程：

• 假设有一个最新的 release kernel 版本，记为 5.1
  • 有 100 个 developer 在 5.1 的基础上开发
• kis 周期性检查这些 100 个 developer 的 tree
  • 如果有新的 commits，尝试合并到 kis 的内核上。 合并成功则进入 “编译、运行、分析、报告”
  • 无需等待 “编译、运行、分析、报告” 完成，即可检查下一个 tree 有没有新的 commits。 如果有，合并到 这个已经合并了新 commit 的内核上。 然后取消之前的 “编译、运行、分析、报告”，在合并了这两个 commits 的基础上进入 “编译、运行、分析、报告” 。
  • 如果某个 commits 合并失败，那么不管这个 commits。并且 [可选的] 通知这个 commits 对应 tree 的维护者。
  • 如果 “编译、运行” 失败，那么可以 bisect。
  • 为什么要在包含了很多 commits 的内核上 “编译、运行、分析、报告”： 假设内核开发者是职业的，所以即使包含了很多 commits 的内核也很大概率会一次成功。那种情况下，我们的策略能够有效提升效率。

得到的基础结论：

• 我们和 wfg 有一个重要的区别——我们的所谓 '分布式' 是 Internet 的，不是 cluster 的
  • 所以应当尽量将数据存储在本地，减少传输；必要时使用计算而不是传输
• KIS 系统中，效率是 极其 重要的

任务分派：

• 最近的任务是针对每个人分派的部分，看已有框架（参见 kis-design.md）是怎么做的。
• 部分分派：
  • 获取 / merge：mashplant
  • 编译：hoblovski
  • 运行测试：szx / elliott10