[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] [Bacula-users] Redundant Run in Schedule


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-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilot Consulting.