Add quadlet timer for foreman recurring task (reports:daily)

[archanaserver]

This is for the prototype implementation of recurring task support in foremanctl using quadlet-based systemd timers

[evgeni]

Where do these volumes come from?

[evgeni]

Is the general idea that we define one systemd timer per (old) cronjob and that timer launches a temporary container, runs the magic in it, and then finishes?

[evgeni]

this will require all the secrets and configs mounted like the normal container does, otherwise it can't access the DB and stuff

[ehelms]

I'd have expected to define this quadlet the same way we do for regular services with containers.podman.podman_container. Is that not possible for timers?

[archanaserver]

Yeah so I did this way to start it with templated .container and .timer units to get a working prototype quickly and to control the timer behavior directly. Since I found that containers.podman.podman_container doesn’t create .timer units, I had to template that part anyway.

And plan is to refactor it to define the .container using containers.podman.podman_container, which aligns with how other services are handled in foremanctl. But the .timer will remain a small template for now, since neither podman_container nor podman_generate_systemd currently support generating .timer units and they only handle .container (or .service) definitions.

So question would you prefer that all recurring-task containers follow the same podman_container (state: quadlet) pattern, even if each has its own .timer defined separately? @ehelms @evgeni

[evgeni]

So I think I prefer containers.podman.podman_container to define quadlets, just to make it consistent.

But would also like to open up the following discussion: This PR adds a timer for foreman-rake reports:daily and we expect more to come. A quick glance gives me:

foreman:

15 23 * * *     foreman    /usr/sbin/foreman-rake db:sessions:clear 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
0 7 * * *       foreman    /usr/sbin/foreman-rake reports:daily 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
0 5 * * 0       foreman    /usr/sbin/foreman-rake reports:weekly 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
0 3 1 * *       foreman    /usr/sbin/foreman-rake reports:monthly 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
30 7 * * *      foreman    /usr/sbin/foreman-rake reports:expire 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
0 1 * * *      foreman    /usr/sbin/foreman-rake audits:expire 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
*/30 * * * *    foreman    /usr/sbin/foreman-rake ldap:refresh_usergroups 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log
0 6 * * 0       foreman    /usr/sbin/foreman-rake notifications:clean 2>&1 | gawk '{ print strftime("[\%Y-\%m-\%d \%H:\%M:\%S]"), $0 }' >>/var/log/foreman/cron.log

katello:

00 22 * * 0	root	foreman-rake katello:delete_orphaned_content RAILS_ENV=production >/dev/null 2>&1
00 18 * * 0     root    foreman-rake katello:refresh_alternate_content_sources >/dev/null 2>&1

foreman-tasks:

45 19 * * *    foreman    /usr/sbin/foreman-rake foreman_tasks:cleanup >>/var/log/foreman/cron.log 2>&1

Now, given they all use foreman-rake <something>, I wonder if we can create a template (container) service, and then use timer units to start different instances of this service, running different subcommands?

Sort of like we do for the different dynflow workers today.

[archanaserver]

Is the general idea that we define one systemd timer per (old) cronjob and that timer launches a temporary container, runs the magic in it, and then finishes?

Hmm exactly, so with each legacy cron job maps to its own systemd timer that spins up a short-lived container, runs the rake task (like foreman-rake reports:daily), and exits. I believe it’s a simple one-to-one replacement for now, and later we can look into integrating this into foreman-tasks or a more HA-friendly model. But WDYT? @evgeni

[evgeni]

And yes, I agree, we need a simple replacement now, but long-term should look into moving this to foreman-tasks or similar.

[archanaserver]

As per our discussion, I’ve opened a new PR #288 addressing this. Since this one served as a PoC, I’ll go ahead and close it.