Cyborg Conductor 提案

https://blueprints.launchpad.net/openstack-cyborg/+spec/cyborg-agent

本规范提出了 Cyborg Conductor 的职责和初始设计。

问题描述

Cyborg 需要在控制器主机上运行一个 Conductor 来管理 Cyborg 系统状态并整合数据库操作。

用例

在 OpenStack 中使用连接到虚拟机实例的加速器

提议的变更

Cyborg Conductor 将驻留在控制节点上，并负责 Cyborg 执行的状态性操作。它既可以作为数据库的缓存，也可以作为组合数据库读取和写入操作的方法。所有其他 Cyborg 组件都将通过 Conductor 进行数据库操作。

备选方案

每个 Cyborg Agent 实例独立访问数据库是另一种可能的方案，如果加速器负载监控速率非常低且绝大多数操作是读取，这甚至可能是可行的。但由于我们打算存储定期更新的加速器使用情况元数据，这种模式可能无法很好地扩展。

数据模型影响

“正确”使用 Conductor 将导致几乎没有每个实例的状态，并且状态性操作将通过 Conductor 进行，除了在可以保证其有效的情况下进行一些本地缓存。

REST API 影响

N/A

安全影响

可忽略不计

通知影响

N/A

其他最终用户影响

更快的 Cyborg 操作和更少的数据库负载。

性能影响

通常是积极的，只要我们不会通过尝试将内容传递给 Conductor 进行写入来使消息总线过载。

其他部署者影响

Conductor 必须安装并配置在控制器上。

开发者影响

对于 API 用户来说没有影响，但如果我们要将所有系统状态保存在控制器中，则内部需要大量使用消息传递。

实现

负责人

主要负责人

jkilpatr

其他贡献者

无

工作项

• 实现

• 与 API 和 Agent 的集成

依赖项

• Cyborg API 规范

• Cyborg Agent 规范

测试

该组件应该可以使用单元测试和功能 CI 使用虚拟驱动程序进行全面测试。

文档影响

需要记录一些配置值，用于调整保存速率和控制器上的其他参数，以便最终用户使用。

参考资料

Cyborg API 规范 Cyborg Agent 规范

历史记录

修订版

发布	描述
Pike	引入