On Jan 23, 2014, at 12:20 PM, Greg Hill wrote: > The blueprint is here: > > https://wiki.openstack.org/wiki/Trove/scheduled-tasks > > So I have basically two questions: > > 1. Does anyone see a problem with defining the repeating options as a single > field rather than multiple fields?
Im fine w/ a single field, but more explanation below. > 2. Should we use the crontab format for this or is that too terse? We could > go with a more fluid style like "Every Wednesday/Friday/Sunday at 12:00PM" > but that's English-centric and much more difficult to parse programmatically. > I'd welcome alternate suggestions. 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. 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. /me puts down wrench
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
