Cyborg Agent 提案¶
https://blueprints.launchpad.net/openstack-cyborg/+spec/cyborg-agent
本文档提出 Cyborg Agent 的职责和初始设计。
问题描述¶
Cyborg 需要在计算主机上运行一个 Agent 来管理若干职责，包括定位加速器、监控其状态以及协调驱动程序的操作。
用例¶
在 OpenStack 中使用附加到虚拟机实例的加速器
提议的变更¶
Cyborg Agent 驻留在各种计算主机上，并监控它们以查找加速器。在首次运行时，Cyborg Agent 将运行其安装的所有驱动程序的检测加速器功能。主机上可用加速器的结果列表将报告给 Conductor，Conductor 会将其存储到数据库中并在 API 请求期间列出。默认情况下，加速器将以非活动状态插入数据库。运营商需要手动将加速器设置为“就绪”状态，此时 Cyborg Agent 将负责调用驱动程序的安装函数并确保加速器已准备好使用。
为了镜像 Nova 当前使用 placement API 的模型，每个 Agent 都会将对其资源的更新直接发送到 placement API 端点以及 Conductor，以便进行使用情况汇总。这应使 placement API 保持加速器及其使用情况的最新状态。
备选方案¶
Agent 和 API 端点或驱动程序之间的通信方式有很多替代方案。几乎所有这些方案都涉及我们在驱动程序、Conductor 和 Agent 之间划定界限的位置。我编写的提案的目标是让 Agent 主要充当监控工具，向云运营商或其他 Cyborg 组件报告以采取行动。Cyborg Agent 可以发挥更积极的作用，但这要么需要与 Conductor 进行大量的同步，要么可能会干涉运营商的工作。
数据模型影响¶
Cyborg Agent 将为它检测到的加速器在数据库中创建新的条目，它还将使用加速器的当前状态（高级别）更新这些条目。像给定加速器的当前使用情况这样的临时数据将通过消息传递系统广播，并且不会被存储。
Cyborg Agent 将保留此数据的本地缓存，目的是在系统中断或连接丢失时不会丢失加速器状态。
REST API 影响¶
待办事项：一旦我们确定谁负责什么。
安全影响¶
监控能力对攻击者可能有用，但如果没有 root 权限，这只是一个较小的担忧。
通知影响¶
通知用户他们的加速器已准备好？
其他最终用户影响¶
关于添加/删除/设置加速器的交互细节待定。
性能影响¶
Agent 心跳用于更新加速器性能统计数据，这可能会给 Cyborg 端点和数据库带来扩展到许多加速器主机的挑战。也许我们应该考虑在调度实例之前进行主动的“负载普查”？但这只是将问题从持续负载转移到启动风暴的问题。
其他部署者影响¶
通过不将驱动程序与 Agent 放在一起，我们可以保持较小的部署足迹。但是，通过网络发送驱动程序会增加开发复杂性和安全问题。
开发者影响¶
待定
实现¶
负责人¶
- 主要负责人
<jkilpatr>
- 其他贡献者
<launchpad-id 或 None>
工作项¶
Agent 实现
依赖项¶
Cyborg 驱动程序规范
Cyborg API 规范
Cyborg Conductor 规范
测试¶
需要配备一组加速器、驱动程序和硬件的 CI 基础设施，以便定期测试 Agent 的安装和操作。
文档影响¶
几乎没有。也许是在计算配置文件上，可能需要记录。但我认为尽可能避免本地配置是最好的。
参考资料¶
其他 Cyborg 规范
历史记录¶
发布 |
描述 |
|---|---|
Pike |
引入 |
