On Sunday 04 November 2007 21:55, Dan Langille wrote:
> I can this this feature being useful to me when out of town and
> Bacula needs a new tape, but doesn't get one for several days.
Yes precisely.
I was lax with my wording -- I meant Job Level everywhere and not Priority.
Priority is not at all part of this proposal.
Thanks for the clarifications.
So in summary:
Allow Duplicate Jobs = Yes | No | HigherLevel | CancelLowerLevel (Yes)
Where HigherLevel cancels any waiting job but not any running job.
Where CancelLowerLevel is same as HigherLevel but cancels any running job or
waiting job.
Duplicate Job Proximity = <time-interval> (0)
Kern
>
> On 4 Nov 2007 at 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 ?
>
> Priority is mentioned above. Do you mean Priority (as in 1, 5, 10),
> or do you mean Level (as in Inc, Diff, Full)? I think you mean
> Level. I point out other references to Priority below in case
> Priority is meant.
>
> In which case, CancelLowerLevel is more precise.
>
> For what it's worth, the term Single Instance also can to mind...
>
> Now that we're talking about Priority, will Priority have any role in
> these directives?
>
> > 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.
>
> Priority? Or Level?
>
> I agree that in any case, we would never cancel a running job with
> this directive.
>
> > > > 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.
>
> Another way to look at Duplicate Job Proximity is "don't run this job
> again if it has been run within the past 'interval'", which is
> getting into the domain of the Schedule resource. We will need to
> document that one carefully.
>
> > 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.
>
> Going into synonym mode, here are some I thought close to this, in
> case they sound better
>
> collision, nearness, adjacency, zone, neighborhood, range, region
>
> I still think Proximity is best.
>
> > 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
>
> Priority? Or Level?
>
> > (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).
>
> I think keeping some record is a good idea.
>
> > > > 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 ...
>
> Agreed.
-------------------------------------------------------------------------
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
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
