New Cron Framework and Optional Crons

Community
1

I’m trying to implement the new Cron Framework in one of our plugins and we hit a design question: feat: use cron framework by ochnerd · Pull Request #68 · dm-drogeriemarkt/foreman_vault · GitHub .

Their are some cronjobs which are optional and don’t need to run if not needed. What’s the best way to realize that inside of the plugin?

2

Can you elaborate on the “not needed”? Is that a user deciding “I don’t need that feature of the plugin” or is that the plugin saying “I don’t have data to fulfill the request”?

The audits job has something similar: If the audits_period setting is not set, it doesn’t know which audits to expire and just calls next to skip the execution.

You could either perform that decision in code directly, or also add a setting which the user can toggle.

I know there has been some talk to make those tasks actual Foreman tasks, so you can enable/disable them in the UI, but so far it didn’t happen yet.

Maybe @akumari or @aruzicka know more

3

Ahh i see what you mean. It is the User deciding “I don’t need that feature of the plugin”.

4

I am not a huge fan of adding boolean settings, but it would work.

Is there maybe some “push target” that is defined that we could derive from? “push target not set → no run”?

Edit: looking at the code: no. If there is no vault connection, the whole plugin is rather non working XD

5

I like the idea of a central ui for the tasks to enable and disable but I don’t think that is something that will be build in the next weeks :smiley:

Seems like a boolean setting is our best option for now.

6

@evgeni would something like this work?

          settings do
              setting('vault_cron_enabled',
                full_name: N_('Vault Cronjobs enabled'),
                type: :boolean,
                description: N_('Enable or disable the Vault Cronjobs for managing policies and auth methods'),
                default: false)
            end
          end

          if Setting['vault_cron_enabled'] = true
          # Register recurring task with Foreman::Cron framework
            Foreman::Cron.register(:hourly, 'foreman_vault:policies:push')
            Foreman::Cron.register(:hourly, 'foreman_vault:auth_methods:push')
          end

I don’t write ruby often so please have mercy with my idea :smiley:

7

Maybe.

The register happens on boot time of Foreman/Rails, so if you change the setting the currently running Rails process won’t know that change (well, it will know the setting changed, but the register/unregister won’t happen). But as the cron runs happen in a newly spawned Rails process anyway, it probably won’t hurt.

I’d do a next unless Setting['vault_cron_enabled'] inside the Rake job definition instead, but I guess that’s more a personal preference?

8

So with my idea it maybe would need a foreman restart after a change of the setting? That would be bad.

I think your idea might be better. I will test both on our Testsystem.

9

As I said, the actual execution of the cron job happens in a separate process, and that will have the right cron jobs registered.
Only if you go and build a Foreman::Cron dashboard (which doesn’t exist today), it would show wrong data.

1 Like
10

Or if we move it into a persistent foreman-tasks process. I think your suggestion to skip it within the task itself is better. Now that we launch a rails process anyway there is no startup overhead for an individual job anymore.

11

agree that rails is already loaded for that invocation, so yeah there’s no separate rails startup for each job. and checking the setting inside the task and skipping its work seems like the right approach here. and the timer integration itself doesn’t add per-job enable/disable controls.

12

Ok thanks for the fast help. I will be checking the setting inside the task and skip it.

1 Like