On Fri, Nov 25, 2005 at 11:08:50PM +0100, Kern Sibbald wrote:
> On Friday 25 November 2005 22:32, Ross Boylan wrote:
....
> > What should we call those things that are scheduled but have not yet
> > run?
>
> Good question. I don't know. Maybe Scheduled Jobs as opposed to Running Jobs.
> This may be the terminology I use in the status output ???
Yes, it is.
>
> >
> > >When a job is deleted, it is removed from the
> > > database, so delete is not a term to use in this Bacula context. The
> > > scheduling of a job could be skipped (perhaps the user would like to
> > > consider this canceling, that is OK).
> >
> > Is "cancel" the right word to describe what I'm looking for? I want
> > the thing that is scheduled not to run, and to be removed from the
> > list of things scheduled?
>
> More suitable word might be "skip" if you want the next scheduled time for a
> job to be skipped, or "disable" if you want to turn off all future
> scheduling ...
This exposes an ambiguity in the use of "job." On the one hand, it
can refer to a particular piece of work, which would be identified
with a jobid if it succeeded. On the other hand, it refers to a
general request for work. In the first sense, the job is killed; in
the second sense, it is only skipped or postponed.
In support of interpretation one (job = pariticular work at a
particular time):
1) the output of bconsole status dir, which refers to scheduled,
terminated and running jobs (which make little sense if job has the
second sense);
2) The use of job, and the Job class, in the discussion of python
scripting in the current manual (1.38);
3) the usual useage with computers of job (IMHO).
In support of the second interpretation (job = general request for work):
1) The meaning of the Job keyword in the director file;
2) the use of the Job attribute in python scripting ("The following
read-only attributes are available with the Director for the job
object.");
3) The terminology entry for "job" in the current manual: "A Bacula
Job is a configuration resource that defines the work that Bacula must
perform to backup or restore a particular Client."
I'd say that none of this matters, except that I seem to be getting
tripped up a bit by it :) And the presence of python scripting seems
to be exposing more of these clashing interpretations.
Ross
>
> We might be able to do something like:
>
> skip job=Job-name
>
> which would skip the next scheduled time for Job-name
>
> and
>
> disable job=Job-name
>
> which would turn off all future scheduling of Job-name until:
>
> enable job=Job-name
>
> but this is a Feature Request that someone would need to submit ... :-)
>
> Oh, yes, disable and enable should probably work for other things such as
> Autochangers and Devices too -- hmmm perhaps even someday Storage daemons and
> Clients ...
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
