创建调度器 Python 库

https://blueprints.launchpad.net/nova/+spec/scheduler-lib

我们希望将 nova-scheduler 分离成 gantt。为此，我们需要将调度器从 nova 的其余部分隔离出来。

在这个蓝图中，我们需要在一个清晰的库中定义从 nova 的其他部分（conductor 和 ResourceTracker）访问调度器代码或数据（compute_nodes DB 表）的所有访问。

此蓝图不会影响调度器的任何代码，更改仅影响 nova 的其他组件，并为调度器提供一个新的模块。

问题描述

为了创建 gantt 项目，我们需要在 nova-scheduler 和 nova 的其余部分之间引入一个更清晰的“界限”。这将允许现有的 nova-scheduler 代码保留在 Nova 中，同时为我们提供一种干净的方式来测试新的 gantt 调度器。

这种分离也将有助于允许像 no-db-scheduler 这样的努力以一种允许多种模式共存的方式发展，从而鼓励更多的创新，同时保持现有的稳定和可插拔的解决方案。

在 Nova Icehouse 中期会议上，对 gantt 项目的这种方法达成一致：https://etherpad.openstack.org/p/icehouse-external-scheduler

提议的变更

关于此更改的基本要点是

  • 行为没有变化。这只是一个重构。

  • 创建一个调度器库，为 python-ganttclient 提供一个原型接口

  • 假设到 Juno 结束时，select_destinations 将是 nova 从 nova 调用调度器的唯一调用。这是接口的第一部分。

  • 将所有访问 compute_nodes 表的访问都移到新的调度器库之后。这是接口的第二部分。

在这里，我们需要通过暴露 Nova 可以使用（主要是 ResourceTracker）的调度器接口来定义一条界限，用于更新调度器的统计信息，而不是直接调用 DB 来更新 compute_nodes 表。

此外，对调度器 RPC API 的调用现在将通过调度器库进行，以便所有当前接口都指向同一个模块。但鉴于上述假设，我们只需要对 select_destinations 执行此操作。

如前所述，所有接口都将进入一个模块（nova.scheduler.client）。

我们目前识别的接口是

select_destinations(context, request_spec, filter_properties)
    """Returns a list of resources based on request criterias.
    """
    :param context: security context
    :param request_spec: specification of requested resources
    :type requested_resources: dict
    :param filter_properties: scheduler hints and instance spec

update_resource_stats(context, name, stats)
    """Update Scheduler state for a set of resources."""
    :param context: context
    :param name: name, as returned by select_destinations
    :type name: tuple or string
    :param stats: dict of stats to send to scheduler

如果我们仍然需要在 nova 中支持节点和主机的区分，可以通过将元组 (host, node) 作为资源名称传递，而不是字符串来实现。

类似地，resource_request 将包含 request_spec 和 filter_properties，目前都包含在一个通用的字典中。

stats 参数计划与 conductor/DB compute_node_update() (或 create()) 值参数 1:1 匹配，即与 compute_nodes 字段匹配的字典，采用 JSON 格式。

这个提议只是划定了一条界限。在未来，我们需要进行更多具有侵入性的更改，这些更改不在此蓝图的范围内，例如

  • 将更多数据添加到 compute_nodes 中，以便调度器不需要访问任何其他 Nova 对象。例如，需要了解 AZ 的过滤器，可以将其包含在添加到 compute_nodes 的统计信息中

  • 拥有一个数据收集插件系统，以便从资源跟踪器提取数据并将其发送到调度器，格式与接收端的过滤器和/或权重匹配。同时确保仅发送特定过滤器和/或权重所需的數據。这与可扩展的资源跟踪器蓝图非常相似，或者可以利用它。

  • 通过另一种方法代理 select_destinations，使其不那么 Nova 特定的，并允许未来的 python-ganttclient 客户端使用它。

备选方案

另一种选择是在某个时间点将调度器代码分叉到一个单独的 Git 仓库，进行必要的更改（单元测试、导入）。然而，同步更改或对 nova-scheduler 进行代码冻结似乎不是最好的方法。

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无。这项工作只是重构，现在并没有拆分成一个单独的仓库。

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

理想情况下

  • 所有新的操作都将使用 select_destinations 进行调度。

  • ResourceTracker 将仅使用 update_resource_stats。

实现

负责人

主要负责人

sylvain-bauza

其他贡献者

无

工作项

  • 创建调度器库以调用 select_resources

  • 将 update_resource_stats 添加到库中

依赖项

测试

涵盖了现有的 tempest 测试和 CI。

文档影响

无

参考资料