Allow drivers to have their own periodic tasks¶
This spec suggests allowing Ironic drivers to define their own periodic tasks.
Currently Ironic conductor can run periodic tasks in a green thread. However, if some driver requires a driver-specific task to be run, it needs to patch conductor manager, which is not acceptable.
Proposed use cases:
For in-band inspection using discoverd driver-specific periodic task would be used to poll discoverd for inspection status.
For DRAC RAID implementation driver-specific periodic task may be used again to poll status information from BMC.
For deploy drivers supporting long-running ramdisks (e.g. IPA) a driver-specific periodic task may be used to poll for dead ramdisks when nothing is deployed on a node.
Create a new decorator
@ironic.drivers.base.driver_periodic_taskto mark driver-specific periodic tasks. It will mostly delegate it’s job to
@periodic_task.periodic_taskwith the exception of additional argument
Until parallel periodic tasks is implemented in Oslo,
parallel=Truewill be implemented by wrapping the task into a function calling
eventlet.greenthread.spawn_nto make it run in a new thread. It will also use Eventlet semaphore to prevent several instances of the same task from running simultaneously.
ConductorManager.__init__to collect periodic tasks from each present interface of each driver. It should use existing markers added by
@periodic_task.periodic_taskto a method to detect periodic task. Information about a periodic tasks should be placed in
_periodic_tasksattributes of the conductor.
The future modification should be adding something like
PeriodicTasksclass in Oslo. The only thing that prevents me from suggesting it is that
PeriodicTasksclass is under graduation into a new oslo.service now. No changes are allowed at the moment. This should be done as a refactoring step later.
oslo.serviceis graduated and parallel periodic tasks are implemented there, get rid of the work around inside
driver_periodic_task, and switch to using parallel periodic tasks from Oslo.
Each time modify conductor when we need a periodic task. That requires a consensus on how to make it in a generic way.
LoopingCall. I believe that this approach is less controlable (in terms of how many threads we run, how many requests we make to e.g. DRAC BMC etc) and leads to code duplication.
Data model impact¶
REST API impact¶
RPC API impact¶
Driver API impact¶
No impact for the driver API itself.
Nova driver impact¶
Other end user impact¶
This will allow large number of periodic tasks to be added to Ironic.
parallel=True should minimize effect on performance.
The decision of whether to add or not a new tasks is anyway to be done on a
Other deployer impact¶
Note that periodic_max_workers and rpc_thread_pool_size configuration options are not affecting driver-specific periodic tasks.
Driver developers can mark any method as a
- Primary assignee:
Dmitry Tantsur, LP: divius, IRC: dtantsur
parallel periodic tasks are nice to have, but is not a hard dependency.
Unit testing will be conducted.
Upgrades and Backwards Compatibility¶
Update driver interface documentation to mention how to create periodic tasks.
Parallel periodic tasks spec: https://review.openstack.org/#/c/134303/