Open Stack

On Jan 23, 2014, at 3:41 PM, Michael Basnight <mbasnight at gmail.com> wrote:

> 
> 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".

> 
> Will we be using this as a single task service as well? So if we assume the first paragraph is true, that tasks are scheduled daily, single task services would be scheduled once, and could use the same crontab fields. But at this point, we only really care about the minute, hour, and _frequency_, which is daily or once. Feel free to add 12 scheduled tasks for every 2 hours if you want to back it up that often, or a single task as * 0/2. From the backend, i see that as 12 tasks created, one for each 2 hours.

I hadn't really considered anything but repeated use, so that's a good point.  I'll have to think on that more.  I do think that the frequency won't only be "daily" or "once".  It's not uncommon to have weekly or monthly maintenance tasks, which it was my understanding was something we wanted to cover with this spec.   I'll do some research to see if there is a suitable standard format besides cron that works well for both repeated and scheduled singular tasks.

> But this doesnt take into mind windows, when you say you want a cron style 2pm backup, thats really just during some available window. Would it make more sense for an operator to configure a "time window", and then let users choose a slot within a time window (and say there are a finite number of slots in a time window). The slotting would be done behind the scenes and a user would only be able to select a window, and if the slots are all taken, it wont be shown in the "get available time windows". the "available time windows" could be smart, in that, your avail time window _could be_ based on the location of the hardware your vm is sitting on (or some other rule…). Think network saturation if everyone on host A is doing a backup to swift.

I don't think having windows will solve as much as we hope it will, and it's a tricky problem to get right as the number of tasks that can run per window is highly variable.  I'll have to gather my thoughts on this more and post another message when I've got something more to say than "my gut says this doesn't feel right".

Greg