Hi, 20.02.2008 21:41, Bastian Friedrich wrote: > Hi, > > On Mittwoch 20 Februar 2008, Arno Lehmann wrote: >> 20.02.2008 15:31, Bastian Friedrich wrote: >>> [...] it is not >>> difficult to circumvent, either: >>> Run = Full Pool = PoolSpecial w01 mon at 8:00 >>> Run = Full Pool = Pool w01 w02 w03 [...] w53 mon at 8:00 >>> runs the second job only if the first job is not run. >> Really sure? > > Glll. Typo. Should have been "w00 202 [...]" in the second case, of > course.
Good... I was a bit worried about my understanding of schedules :-) >> I think it would run both jobs, but haven't checked myself. > > Of course it does. Stupid me. > >> I have to borrow Dan's question: What do you want to achieve here? > > We are trying to generate Bacula schedules from other means of > configuration. Considering a little more interesting backup strategies, > the Bacula schedule configuration statements lack a means of "negating" > points of time - or a "either/or" semantics as described here. > > In one point or another, I'll have to remove redundant "run" > statements - either in our generating code, or somehow/somewhere inside > Bacula. Both seem to be valid choices; I am currently examining them. Ok... currently, the simplest solution might be to generate the configuration accordingly, i.e. create schedukes that don't run these jobs twice. With schedules, what you want to achieve is indeed not possible. It *might* be possible using a python event in a way that you just start the job with any level and pool, and the python part sets the actual level and pool to run. I don't know if this is possible, and given the somewhat limited future of python events in Bacula I wouldn't dig into it... > It is perfectly legal (and sensible) to run a job e.g. "once a month" > (1st mon) to one pool, and "every day" to another pool. Currently, one > would need to use one "tue-sun" plus one "2nd 3rd 4th 5th mon" > statement. If run statements in schedules were exclusive (given they > would be run at an identical time), the configuration would be less > complicated. I may be wrong, but I don't see much of a point in running > the same job (just different levels and pools) twice at the same time. Oh, there are uses for this :-) > On the other hand, as I said: the problem can be circumvented with a > little more complex configurations. Which is the way to go, currently. If you thing about a feature request you should be aware that it's very unlikely a modification of the schedules behaviour would be accepted that changes the current behaviour; you'd need a way to make sure current installations run just like now. A new keyword in the run= line in a schedule might be accepted, but I doubt this will be of a high priority... If you prepared a patch that, for example, implements an "override" keyword which would run the job and not run identical jobs, instead of adding it, I'm sure Kern and others would seriously consider it :-) Arno > Thx > Bastian > -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
