[openstack-dev] [trove] scheduled tasks redux

Kevin Conway kevinjacobconway at gmail.com
Fri Jan 24 16:15:19 UTC 2014


>
>Will we be doing more complex things than "every day at some time"? ie,
>does the user base see value in configuring backups every 12th day of
>every other month? I think this is easy to write the schedule code, but i
>fear that it will be hard to build a smarter scheduler that would only
>allow X tasks in a given hour for a window. If we limit to daily at X
>time, it seems easier to estimate how a given window for backup will look
>for now and into the future given a constant user base :P Plz note, I
>think its viable to schedule more than 1 per day, in cron "* 0,12" or "*
>*/12".

Scheduling tasks on something other than a daily basis can be a legitimate
requirement. It's not uncommon for organizations to have "audit dates"
where they need to be able to snapshot their data on non-daily, regular
intervals (quarterly, annually, etc.).

I also like the idea of windows. I know that one of the features that has
also been requested that might be satisfied by this is allowing operators
to define maintenance windows for users to select. Maintenance could
simply be a task that a user schedules in an available window.

If the concern over allowing hard times for scheduled tasks, backups as
the given example, is saturation of external resources like networking or
Swift then it might be more beneficial to use windows as a way of
scheduling the availability of task artifacts rather than the task itself.
When I used to work in government/higher education, for example, there
were multiple dates throughout the year where the organization was
mandated by the state to provide figures for particular calendar dates.
The systems they used to manage these figures typically did not provide
any means of retrieving historic values (think trying to audit the state
of a trove instance at a specific point in the past). As a result they
would use automated backups to create a snapshot of their data for the
state mandated reporting. For them, the backup had to begin a 00:00
because waiting until 04:00 would result in skewed figures.

I'm not certain how common this scenario is in other industries, but I
thought I should mention it.





More information about the OpenStack-dev mailing list