Build st2 timers list just like st2 webhooks list.

[lakshmi-kannan]

st2 timers list would be immensely useful for users. st2 timer delete can also be an option but then we might delete a timer and not the associated rule.

[codyaray]

What would this return exactly? The entries from trigger_d_b? I'd love the output of apscheduler#printjobs. I was about to try to hack access to this myself (or query mongo to roll my own).

[Kami]

I do think that the idea of exposing active timers through CLI in some more readable form than rules is a good one (e.g. runs every day at X, next scheduled run today at X).

I would personally keep it to read-only though because allowing user to delete timers could cause consistency and other issues.

[lakshmi-kannan]

@codyaray: Yes, I am planning to output contents of trigger_d_b and maybe edit the model to include the rule ref. It will also include the timer parameters. I already opened a PR: #2965

@Kami Yep, I just have read only API calls for now.

[lakshmi-kannan]

@codyaray When you get a chance, could you post a sample output of apscheduler#printjobs? It will save me some time. Also, please see #2977 for some CLI samples and API samples I posted in PR description.

[codyaray]

Hi @lakshmi-kannan - The other day I tried to find the easiest way to see this output myself.

In /opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/timer/base.py:

    def add_trigger(self, trigger):
        self._add_job_to_scheduler(trigger)
        self._scheduler.print_jobs()

The actual logs themselves were disappointing. Think it might just be easier to script over mongodb directly than try to leverage this helper function. Maybe use python-crontab if you want to see the specific next run date (which is admittedly cool).

2016-10-20 15:54:22,746 INFO [-] Job 2c8da11f5d2a412793787a0a0c50a33c scheduled.
Jobstore default:
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='mon-fri', hour='20', minute='0'], next run at: 2016-10-20 20:00:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='*', hour='22', minute='0'], next run at: 2016-10-20 22:00:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='mon-fri', hour='23', minute='0'], next run at: 2016-10-20 23:00:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='*', hour='23', minute='58'], next run at: 2016-10-20 23:58:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='*', hour='2', minute='0'], next run at: 2016-10-21 02:00:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='*', hour='2', minute='30'], next run at: 2016-10-21 02:30:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day_of_week='0-4', hour='3', minute='0'], next run at: 2016-10-21 03:00:00 CDT)
    St2Timer._emit_trigger_instance (trigger: cron[day='*', day_of_week='*', hour='4', minute='30'], next run at: 2016-10-21 04:30:00 CDT)

[codyaray]

Been playing with this a bit. You can give the job a name when calling add_job that gets printed.

Here's from my little helper test script

            scheduler.add_job(lambda name: name, args=[names[i]], trigger='cron', name=names[i],
                              minute=cron.minute, hour=cron.hour, day=cron.day, month=cron.month, day_of_week=cron.dow)

When I print the schedule now, I see stuff like

    cleanlogs_someapp_somehost (trigger: cron[month='*', day='20', day_of_week='*', hour='3', minute='0'], next run at: 2016-11-20 03:00:00 CST)

So perhaps just including this parameter in add_rule would let print_jobs work better?