Re: [Bacula-users] [Bacula-devel] Mini project

[Arno L. <al...@it...>]

Hi,

04.11.2007 19:15,, Kern Sibbald wrote::
> On Sunday 04 November 2007 18:31, David Boyes wrote:
>>> 1.  Allow Duplicate Jobs  = Yes | No | Higher   (Yes)
>> Looks OK. One question: if a lower level job is running, and a higher
>> level job attempts to start, does this imply that the lower level job is
>> cancelled, and the higher level one is run instead? I think this is
>> desirable behavior if possible (or maybe it might require an additional
>> option of Supercede for this directive to enable this behavior).
> 
> I hadn't planned to cancel the lower priority job, but I had thought about the 
> possibility.  However, now that you mention it, I think we need some keyword 
> to do this.  Any suggestions?  -- CancelLower, HigherWithCancel ?

Your project sounds good to me, and Davids suggestion is what I'd 
prefer. The "CancelLower" keyword sounds correct to me - it describes 
what will be happening.

> By the way, if a lower priority job is scheduled, but not running, I was 
> planning to cancel it.  A new keyword would certainly clarify what should 
> happen.
> 
>>> 2. Duplicate Job Interval = <time-interval>   (0)
>> The semantics look fine, but a usability suggestion:
>>
>> Since you're really setting a proximity guard interval, it might be
>> easier to understand for the end user if you used Duplicate Job
>> Proximity rather than Interval. That would give the implication of "no
>> closer than" that I think you want, and it might translate better.
> 
> Yes, I was thinking of calling it Duplicate Job Delay, but that was confusing.  
> I think "Duplicate Job Proximity" will be the most clear.  Thanks.

I agree.

> Another point is that I could do a lot of this in the scheduler -- i.e. just 
> not run jobs if one was already running, but I think I will actually "start" 
> the job, print a message, then cancel it if it is of equal or lower priority 
> (i.e. not supposed to run).  That way, there will be some record.   We might 
> even want to invent a new message class (for example: AutoCancelled) so that 
> the job output from such jobs could be sent elsewhere (i.e. down the bit 
> bucket if one wants).

The scheduler would be the logical place for this, I think (assuming 
that manually started jobs are feed through the scheduler, i.e. also 
affect the suggested behaviour, and are affected by it).

>>> PS: I think the default for Allow Duplicate Jobs should be Higher, but
>>> that
>>> would change current behavior ...
>> I agree with you. It's dumb to do an incremental followed immediately by
>> a full backup if they're going to dump the same data in roughly the same
>> timeframe.
> 
> Yes, but I always hesitate to make non-compatible changes ...

I'd also prefer to keep the defaults in a way that reproduces the 
current behaviour.

Arno

> Thanks for the ideas,
> 
> Kern
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Bacula-users mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> 

-- 
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de