允许驱动程序拥有自己的周期性任务

https://blueprints.launchpad.net/ironic/+spec/driver-periodic-tasks

此规范建议允许 Ironic 驱动程序定义自己的周期性任务。

问题描述

目前 Ironic conductor 可以使用绿色线程运行周期性任务。但是，如果某个驱动程序需要运行特定于驱动程序的任务，则需要修补 conductor 管理器，这是不可接受的。

建议的使用场景

  • 对于 使用 discoverd 进行带内检查，特定于驱动程序的周期性任务将用于轮询 discoverd 以获取检查状态。

  • 对于 DRAC RAID 实现，再次可以使用特定于驱动程序的周期性任务来轮询来自 BMC 的状态信息。

  • 对于支持长时间运行的 ramdisk 的部署驱动程序（例如 IPA），可以使用特定于驱动程序的周期性任务来轮询在节点上未部署任何内容时的死 ramdisk。

提议的变更

  • 创建一个新的装饰器 @ironic.drivers.base.driver_periodic_task 来标记特定于驱动程序的周期性任务。它将主要将其工作委托给 @periodic_task.periodic_task，唯一的例外是额外的参数 parallel 默认值为 True。

    在 并行周期性任务 在 Oslo 中实现之前，parallel=True 将通过将任务包装在一个调用 eventlet.greenthread.spawn_n 的函数中来运行在新线程中来实现。它还将使用 Eventlet 信号量来防止同一任务的多个实例同时运行。

  • 修改 ConductorManager.__init__ 以从每个驱动程序的每个存在的接口收集周期性任务。它应该使用由 @periodic_task.periodic_task 添加到方法的现有标记来检测周期性任务。周期性任务的信息应放置在 conductor 的 _periodic_spacing _periodic_last_run 和 _periodic_tasks 属性中。

  • 未来的修改应该是在 Oslo 的 PeriodicTasks 类中添加类似 add_periodic_task 的内容。阻止我提出它的唯一原因在于 PeriodicTasks 类正在 毕业到新的 oslo.service 中。目前不允许进行任何更改。这应该作为后续的重构步骤来完成。

  • 一旦 oslo.service 毕业并且 并行周期性任务 得到实现，就删除 driver_periodic_task 内部的解决方法，并切换到使用来自 Oslo 的并行周期性任务。

备选方案

  • 每次修改 conductor 时，如果我们需要一个周期性任务。这需要对如何以通用方式进行达成共识。

  • 只需使用 LoopingCall。我认为这种方法可控性较差（在运行多少线程、向例如 DRAC BMC 发送多少请求等方面），并会导致代码重复。

数据模型影响

无

REST API 影响

无

RPC API 影响

无

驱动程序 API 影响

对驱动程序 API 本身没有影响。

Nova 驱动程序影响

无

安全影响

无

其他最终用户影响

无

可扩展性影响

预计没有

性能影响

这将允许向 Ironic 添加大量周期性任务。默认情况下 parallel=True 应该最大限度地减少对性能的影响。无论如何，添加新任务的决定都应逐案进行。

其他部署者影响

无。

请注意，periodic_max_workers 和 rpc_thread_pool_size 配置选项不会影响特定于驱动程序的周期性任务。

开发人员影响

驱动程序开发人员可以将任何方法标记为 @driver_periodic_task。

实现

负责人

主要负责人

Dmitry Tantsur, LP: divius, IRC: dtantsur

工作项

  • 添加 ironic.drivers.base.driver_periodic_task 装饰器

  • 修改 ConductorManager.__init__。

  • 建议在 oslo.service 中添加 add_periodic_task。

依赖项

测试

将进行单元测试。

升级和向后兼容性

无

文档影响

更新驱动程序接口文档，以说明如何创建周期性任务。

参考资料

并行周期性任务规范：https://review.openstack.org/#/c/134303/