Feature Proposal: Action Scheduler

[diellenne]

Currently it is not possible to dynamically schedule the execution of actions or workflows: it can be done using the rules but these are static, so if you want to include some logic regarding when (and if) a task need to be executed, you need to implement this logic in the action's body.

We would like to propose the introduction of of a scheduler for running actions and workflows.

This scheduler not only allows users to schedule actions and workflows, but also re-schedule based on logicconditions (perhaps YAQL?) and return information relating to the scheduler queue such as depth and a read out of each task and it's planned execution.

The scheduler should also return an ID to inspect current scheduled state along with results on completion.

Look forward to the response. We believe this will be of value to the wider community.

[arm4b]

There is already scheduler for actions/workflows, see core.st2.CronTimer, core.st2.DateTimer and core.st2.IntervalTimer examples: https://docs.stackstorm.com/rules.html#timers

Seems like it's what you're looking for so I'm closing this feature request.

[diellenne]

Of course you can define a static rule triggering a specific action at a specific time: it's what I'm doing at the moment but in this way the all conditional logic is coded in the action. What I mean is to have the possibility to dynamically set the execution time of an action (based on conditions that can be checked -for example - in a workflow defintion) and something similar to the execution history that gives you an overview of all the actions waiting to be executed.

[arm4b]

Of course you can define a static rule triggering a specific action at a specific time: it's what I'm doing at the moment

It's a bit different comparing to what I'm understood from your first message with using core Linux at tool:

We use the Linux at command to schedule commands that run actions and workflows. It's a work-around but not ideal.

Alright, re-opening the proposal. Please modify the first message to be more clear with expectations/designs and how you see the feature request.

[mindcreations]

I'm a noob of Stackstorm, so don't blame on me if I say something obvious :)

Currently I'm working on a service that needs to do an API call on a specified time (like at) and I'm evaluating to use StackStorm to avoid creating a scheduler on my own. Consider that my task could lay in the queue even for 1 month or more before being effectively executed. See it as a "very postponed" task. So I need to see the pending tasks.

I was evaluating Rundeck also for the same purpose but I see that is somewhat limited on web service requests (plugin) and requires customizations.

Like @diellenne said, it will be very useful to have a dashboard that gives you an overview of all the actions waiting to be executed. Even in my case the right time to schedule the API call has to be dynamic; eg. when I call the webhook on StackStorm to enqueue the task, the execution time will be passed in the POST body and so the timer should be scheduled accordingly.

[namachieli]

My Use case:

When i have a Change that comes in from ServiceNow, I want to be able to take the start date, and schedule a workflow to run based on that. This will be fairly dynamic so creating a rule isn't quite feasible. I can use the workaround of at for now, but something integrated would be great.

[Kami]

@namachieli With the recent scheduler changes introduced in v2.10.0 you can now also utilize new delay attribute when scheduling an execution.

At the moment, this attribute takes a relative amount (number of milliseconds execution should be delayed for), but there is nothing preventing you to calculate this relative delay based on the current time and when the execution is supposed to run.

Having said that, this recent scheduler change should allow us to relatively easily also implement absolute delays aka "run_at" or similar approach (I believe we already have 90% of the internal changes we need, it's just a matter of exposing the correct "API" to the end user).

In fact, I might look at this in the near future, because I need to update our current retry policy to utilize this new feature and those changes are somewhat related :)

/cc @bigmstone

[arm4b]

Someone from our team was working on this functionality for v3.2 and there is a WIP sketch in #4773. However the development on this feature had stopped and due to quality concerns I'm removing this feature from the v3.2 milestone plan.

If anyone's interested in implementing this feature, - there is a good start in #4773, - we welcome opening a new PR based on it and contribute the solution that's well tested and polished.