support a cron expression

[clescot]

Hi,
it would be useful to support a cron expression, as an alternative to a delay.
If the merge with the https://github.com/iainmckay/docker-mysql-backup project occurs, a cron expression will be present in the resulting merge.

best regards,

Charles.

[deitch]

I like it very much. We have an open issue at iainmckay/docker-mysql-backup#2 where we are discussing it.

[patakijv]

Is it still being considered to handle scheduling inside the container using cron instead of a continuous run and wait loop?

[deitch]

It hasn't been discussed in quite some time, still very open to it.

How would it work? Are you just thinking of a different scheduling UI, so instead of DB_DUMP_BEGIN and DB_DUMP_FREQ, it would take a crontab expression?

I assume the implementation would continue to use a loop for actual implementation, just match by the crontab format?

[michabbb]

i personally feel very comfort with the while loop, because every extra service that is involved, can cause trouble, so less dependencies, less problems. because of the RUN_ONCE logic here, i can use the cron of my host where the container is running, which is perfectly fine for me,
because usually a container does not need a cron, the host instead, always has one, so why install a 2nd service if i already have one? but these are only my personal thoughts about that....

[patakijv]

@deitch I think the crontab entry format variable as an alternative to the begin/freq variables implementation would be easiest to keep it simple. It should only be an override to default behavior so other people who want to use it as a run once if they choose would just use the current default implementation.

An example of another approach with a separate wrapper image for the cron implementation referencing the lower level (this) image to implement the cronjob control is another idea - so the cron implementation at the docker level comes in as an alternative but with a second image layer above the main image (i.e. mysql-backup-cron that uses FROM deitch/mysql-backup). Just another idea.

In our case, the goal would be to remove the need for the host to use cron to manage the jobs, to keep all things configurable in one place (i.e. the docker-compose file) and to further reduce the need to have access to the host at that level but still have all of the controls one would expect if they were administering at the host level (i.e. standard tools like cron, just in the container)

[deitch]

the goal would be to remove the need for the host to use cron to manage the jobs, to keep all things configurable in one place (i.e. the docker-compose file) and to further reduce the need to have access to the host at that level but still have all of the controls one would expect if they were administering at the host level (i.e. standard tools like cron, just in the container)

That makes sense. The less you need the host, the more you can stop caring where it runs (and security is better).

[deitch]

I am struggling with the cron algorithm. How to parse a cron expression and get a result that says, "next time to execute will be in x seconds". Any ideas?

[deitch]

It actually is easy to say, "should I do this now", but much harder to say "when should I do this next?" Systems with actual cron just go ahead and test every second, and get a boolean true/false. I would like to avoid that expensive loop for an administrative process.

[deitch]

See #83 . Initial testing is good, would love to see more.