从计算节点分离服务¶
https://blueprints.launchpad.net/nova/+spec/detach-service-from-computenode
移除服务和计算节点之间的嵌套依赖关系
问题描述¶
没有充分的理由在服务（消息总线的表示）和计算节点（调度器专用的资源集合）之间保持依赖关系。它们之间的关联导致资源跟踪器需要先查找‘compute’主题的服务记录和资源跟踪器的宿主机，然后获取与该查询匹配的服务记录相关的第一个计算节点记录。资源跟踪器没有理由这样做，除非计算节点表具有 service_id 字段以及与服务表的关联。
它还对计算节点表产生依赖，因为在与调度器完全无关的单独表上存在外键，这阻止了调度器的拆分，除非我们继续维护这种关系。
用例¶
这是一项重构工作，有助于通过减少其需要管理的依赖关系来拆分调度器。
项目优先级¶
此蓝图是‘scheduler’重构工作的一部分，被定义为 Kilo 版本的第三优先级。
提议的变更¶
与其使用外键建立关系，该方案将包括为计算节点添加一个名为‘host’的新字段，并在 (host, hypervisor_hostname) 上添加唯一约束。同时，compute_nodes 表中的 service_id 字段将被标记为已弃用且不再更新，ComputeNode 对象字段 service_id 将保持未设置状态。SQLA 关系将从 service 中删除，Service 对象将保留一个 compute_node 字段，但实际上将不会使用这种关系。
实现方案可以在补丁系列 [1] 中找到。
备选方案¶
仅更改 DB API 以删除关系，而不更改调用者，但这会造成一些混淆并掩盖修改访问器的必要性。
数据模型影响¶
大部分更改是关于更改模型，但让我们重新措辞一下。compute_nodes.service 关系将被删除，compute_nodes.service_id 将被标记为已弃用且 Kilo 计算节点不再更新它，compute_nodes.host 将被添加为字符串（与 Service.host 字段相同）。
正如在峰会上达成的共识，将不会进行数据迁移来更新创建 host 列（用于填充其值）或通过重新填充 service_id 来降级。
相反，数据迁移（此处为 service_id 到 host）将在每次发生保存操作时在对象级别（此处为 ComputeNode）进行管理，通过查询 Service 对象获取 host 值并将 service_id 设置为 NULL。
没有必要保留特定的 ID，因为元组 (host, node) 被识别为标识计算节点的真实来源。
ComputeNode 对象仍然会继续拥有 service 字段，但它将不再使用关系来获取该信息。同时，Service 对象将继续拥有嵌套的 ComputeNode 对象以保持向后兼容性，但也不会使用关系来获取该对象。
REST API 影响¶
为了保持 API 稳定性，当我们查询计算节点时，我们仍然会提供服务信息，但这些额外信息将根据需要通过传递给 DB API 的额外标志来确定，该标志要求在 service.host == compute_nodes.host 上连接 service 和 compute_nodes 表。我们预计不会有性能损失，因为这已经在 db.compute_node_get_all() 中以 INTEGER 匹配而不是 VARCHAR(255) 的方式完成。
API 模型没有变化。
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
可以提供一个外部工具来迁移尚未设置 host 字段的现有离线计算节点。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
sbauza
- 其他贡献者
无
工作项¶
代码已经作为补丁系列 [1] 发布
将 host 字段添加到 compute_nodes 表
添加查询此新字段的额外方法
使用这些额外方法而不是查询 Service 来获取节点
使服务信息在查询计算节点时变为可选
删除 compute_nodes 上的 service_id 查询
在查询计算节点时默认不提供服务信息
弃用 compute_nodes 中的 service_id 字段并删除 service 关系
依赖项¶
无
测试¶
当前的 Tempest 和单元测试已经涵盖了这一点。
文档影响¶
无
参考资料¶
以前这是一个错误：https://bugs.launchpad.net/nova/+bug/1357491
[1]: https://review.openstack.org/#q,topic:bp/detach-service-from-computenode,n,z
