Plugins » foreman-tasks

Withing https://projects.theforeman.org/issues/27409, the worker's clock object is used for scheduling the future events that are initiated from within of actions (polling is a typical example https://github.com/Dynflow/dynflow/blob/master/lib/dynflow/action/polling.rb#L93).

Given this introduced additional state that worker needs preserve, it goes against the idea of the worker being as stateless as possible. Therefore, a better way would be getting the information about the future events to the orchestrator, that would use it's own clock for emitting them. A possible channel for this data would be the OrchestratorJobs::WorkerDone job

It will be probably necessary to still use the world.clock in worker for some other cases (the one I can thing of is the heartbeat).

There are multiple possible ways to achieve this. One goal in mind would be to preserve the backward compatibility with existing actions, to avoid upgrade issues.

The options I can think of are:

- Modifying the world.clock to be able to collect the information about future events regarding specific actions, while the other uses of clock would use world.internal_clock instead
- Teaching the clock the fact, that when the a SuspendedAction is the `who` in ping method https://github.com/Dynflow/dynflow/blob/master/lib/dynflow/clock.rb#L134, it should just collect this info, that would be then sent do the orchestrator. The rest of clock semantics might stay unchanged.

Although we might intoroduce the `clock` as the action property, and keep the data in the context of action during the run, in order to preserve the backward compatibility, I'm afraid we will not be ale to avoid Thread[:current] structure to collect the action-specific clock events.