Hi,
I'll keep my answer on this subject short, as you are obviously currently
working on the topic in a larger scope; I'll add some comments on your new
thread on bacula-devel.
On Friday 22 February 2008, Kern Sibbald wrote:
> On Friday 22 February 2008 15.44:56 Bastian Friedrich wrote:
> >
> > On Wednesday 20 February 2008, Bastian Friedrich wrote:
> > > when configuring multiple "Run"s in a schedule that occur at the same
> > > time, they are run sequentially:
> > > Run = Full Pool = PoolSpecial w01 mon at 8:00
> > > Run = Full Pool = Pool mon at 8:00
> > > results in two executions of the job that refers to the schedule.
> >
> > [...]
> >
> > > I'd have a need for exclusiveness in this case: run the job only in
> > > case it is not referenced before. Would you also regard this as a
> > > sensible modification?
> >
[...]
> >
> > What do you think about this idea/code?
>
> Well, I like the idea (the feature), but I'm a little concerned about the
> solution you propose from several stand points:
>
> 1. I found it hard to understand what you wanted to do until I read the
> code, so I am concerned that this concept could be hard to document
> correctly.
Full ACK. During implementation, I came up with at least three different names
for the topic. Finding a good term to express the restriction of duplicate
job queuing is not simple... Your argument is exactly the reason why I did
not supply a documentation patch in the first place.
If I rewrote these few lines, I'd rather name the flag
"PreventDuplicateQueuing".
> 2. The current list of Run directives are essentially ANDed. That is
> Bacula will walk down the list and schedule all that apply.
Minor problem here: In fact, Bacula "walks up" the list, in a way, at least
compared to the sequence of statements in the config file; in other words:
the list is read "bottom up".
Should we consider reversing the logics in store_run(), i.e. append new Run
statements to the end of the list instead of prepending them?
I'd prefer a semantics of "else", rather than "overwriting" existing Runs.
> I think what
> you really are trying to do is to setup two Run directives to be ORed, and
> perhaps that could be handled by a slightly different syntax such as:
>
> Or {
> Run = Level=Full Pool = PoolSpecial w01 mon at 8:00
> Run = Level=Full Pool = Pool mon at 8:00
> }
> or perhaps some other keyword such as OneOf ... wouldn't that be much
> clearer?
> There would be a bit more work to implement this (not really hard) but
> it seems to me it would be much clearer to the user.
The "Or" (or OneOf, or whatever) ressource would then be living inside a
Schedule statement? Interesting idea; it would then be possible to do
something like
Schedule {
Name = foo
Or {
Run = ...
Run = ...
}
Or {
Run = ...
Run = ...
}
}
On the other hand, I frankly do not have any requirement for this added
complexity, and one new keyword/flag would be sufficient for me.
> 3. It is interesting that this comes just at this moment, because just
> tonight I was starting to work on the new "Duplicate Jobs" directive group
> for Jobs. That is a fairly comprehensive set of directives that tell Bacula
> how to deal with duplicate jobs.
So your "Duplicate Jobs" directive is meant to deal with duplicate executions
of jobs, rather than with duplicate queuings, i.e. would rather not prevent
the jobs to be queued in the first place?
In that case, it might in fact be sensible to have both solutions.
Best
Bastian
--
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
Geschäftsführer: William K. Hite / Boris Nalbach
AG München HRB 158898 . Ust.-IdNr: DE 814464942
\ EXPO, f (lat). Vom mittelalterlichen "ex po" ("ex" == aus, heraus;
\ "po" ist ein veraltetes Wort für "Arsch", zusammengefaßt also:
\ "aus dem Arsch", was soviel bedeutet wie "einfach Scheiße").
-------------------------------------------------------------------------
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
