Rex icon indicating copy to clipboard operation
Rex copied to clipboard

Allow cron to update existing cron entries

Open robrwo opened this issue 5 years ago • 4 comments

To change a cron entry, it first needs to be marked absent, changed, and then re-run.

What Ansible and Puppet do is prepend a comment that they use to identify the cron job by resource name, so that changes can be updated.

Perhaps the way to implement this is to provide an optional "update" (boolean) argument to cron_entry (or cron_add). If the update argument is true, then it looks for a line with "Rex: " + resource name rather than the exact cron job.

robrwo avatar May 22 '20 12:05 robrwo

It seems the issue templates were ignored while reporting this one, but I believe it is safe to assume this is a feature request :)

What Ansible and Puppet do is prepend a comment that they use to identify the cron job by resource name, so that changes can be updated.

Yes, and I agree that a similar way to attach "identifiers" for cronjobs would be nice to have in Rex as well. Since they are comments, there wouldn't be too big implementational differences depending on the available crontab provider.

Perhaps the way to implement this is to provide an optional "update" (boolean) argument to cron_entry (or cron_add).

cron_entry is the resource that is supposed to provide an idempotent way to ensure the requested state. I believe the already usual present/absent values for ensure should be able to handle this case without any extra options.

The cron command on the other hand is the imperative interface, and there I would argue that e.g. a cron add should not try an update of an existing job. Perhaps a cron update could be introduced, but then it would still lack a name that could be used as an identifier (which would make it confusable with resources).

Based on that initial details, I think it would be enough to target the implementation of present/absent cases of cron_entry to use the name of the entry as the identifier of the job as a comment in the underlying crontab.

ferki avatar May 26 '20 07:05 ferki

To make upgrading easier, it would make sense to have it fall back to the exact entry for cron jobs if the comment was not found.

robrwo avatar May 27 '20 13:05 robrwo

It took me a while to figure out what you might mean by that exactly, but I believe it's this: "if there's already a cronjob that is an exact match for the timing and the command, just add the comment for it". Is that correct?

ferki avatar May 27 '20 17:05 ferki

It took me a while to figure out what you might mean by that exactly, but I believe it's this: "if there's already a cronjob that is an exact match for the timing and the command, just add the comment for it". Is that correct?

Yes.

robrwo avatar Jun 09 '20 08:06 robrwo