为单元调度交互¶
https://blueprints.launchpad.net/nova/+spec/cells-scheduling-interaction
为了将实例构建调度到计算主机，Nova 和调度器需要考虑到主机被分组到单元中。当 Nova 请求放置决策时，这不一定是显而易见的。
问题描述¶
为了将 Nova 分区为单元，调度器需要在构建过程的早期参与。
用例¶
操作员希望将他们的部署划分为单元，以实现扩展、故障域和构建原因。在分区后，我们需要具有灵活的调度，可以对单元和主机做出决策。
项目优先级¶
Cellsv2 是本周期的一个重点。
提议的变更¶
调度器将在 API 级别被查询，以便它知道将构建传递到哪个单元。实例表存在于单元中，而不是 API 数据库中，因此要创建实例，我们首先需要知道在哪个单元中创建它。
调度器将继续返回一个 (host, node) 元组，调用服务将在映射表中查找主机，以确定它位于哪个单元中。这意味着当前的 select_destinations 接口不需要更改。查询调度器将在 API 返回响应后进行，因此最合理的方法是将构建请求传递给在任何单元之外运行的 conductor。Conductor 将调用调度器，然后在单元中创建实例并将构建请求传递给它。
重新调度仍然将在单元内通过正常的 compute->conductor 循环进行，使用单元内的 conductors。在单元级别添加重新调度将是后续的工作。
有关单元的信息需要被提供给调度器，以便它在放置决策期间考虑到这一点，但这超出了此规格的范围。
备选方案¶
我们可以像在 cellsv1 中那样在两个点查询调度器。这会增加部署复杂性，并创建 Nova 架构和调度器之间不必要的耦合。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
Nova-conductor 需要被部署以供 nova-api 使用。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
alaski
- 其他贡献者
无
工作项¶
添加一个 conductor 方法来调用调度器，然后处理 API 当前为构建请求所做的一切（在数据库中创建实例并将其投递到单元 conductor）。
更新 conductor build_instances 接口，以接收一个调度决策，并且如果提供了该决策，则不调用调度器。这允许从 API conductor 绕过调度，但仍然在 compute 请求重新调度时调用调度器。
更新 devstack 以启动一个 conductor，供 nova-api 服务使用。
依赖项¶
无
测试¶
由于这被设计为 Nova 的内部重构，没有用户可见的更改，因此当前的 Tempest 或功能测试应该足够。在某个时候，我们希望研究如何测试多个 Cell 或潜在地在 API 中公开 Cell 的概念，然后我们将解决测试要求。
文档影响¶
将编写文档，描述实例构建的流程以及调度决策的制定方式和位置。
参考资料¶
https://etherpad.openstack.org/p/kilo-nova-cells https://etherpad.openstack.org/p/nova-cells-scheduling-requirements
