Resent-Date: 26 Jan 1998 17:03:42 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From redhat-devel-list-request@redhat.com  Mon Jan 26 12:03:40 1998
Sender: jonathan@solsbury.carb.nist.gov
Message-ID: <34CCC1D8.C6A4E223@carb.nist.gov>
Date: Mon, 26 Jan 1998 17:03:20 +0000
From: "Jonathan F. Dill" <jonathan@carb.nist.gov>
Organization: CARB
MIME-Version: 1.0
To: Red Hat Software Development List <redhat-devel-list@redhat.com>
CC: smorocho@carb.nist.gov
Subject: qss: proposal for alternative to cron
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"L9QyN1.0.aY.g7Cpq"@mail2.redhat.com>
Resent-From: redhat-devel-list@redhat.com
Reply-To: redhat-devel-list@redhat.com
Precedence: list
Resent-Sender: redhat-devel-list-request@redhat.com

Please Cc me if you respond to this message (I will be travelling and
not checking my e-mail next week, so right now I'm reading the archives
on Red Hat's web site and posting via the post-only list)...

I submit this "proposal" now to encourage feedback, suggestions for
features to make this tool more useful, any pieces I may have "left
out", perhaps get some cohorts to help churn out an alpha version that
we can play around with.  I reserve all copyrights for "qss" so that it
can be distributed under the terms of the GNU Public License and
available for free to the general public.  If anyone else is aware of
some other package called "qss" please let me know and perhaps suggest
some other names (but please not "Alternative Scheduling System" or ASS
;-).  I suppose it's also possible some tool already exists to do this,
but I haven't found one yet--there's NQS, and a couple others, but they
really aren't conveniently designed for running jobs periodically.

I firmly atest to the reliability of Red Hat, but frankly I don't find
it convenient to keep my laptop up and running 24 hours a day 7 days a
week, especially during travel.  I therefore propose an alternative
scheduling scheme (I call it "qss" for "queue-based scheduling system)
geared to laptops and other systems that may need to be shut down
frequently and therefore would not necessarily be up and running at the
cron-appointed times for essential cleanup tasks.  qss would have the
following components:

- a cummulative uptime clock
- submitter, run at startup and then periodically thereafter to submit
tasks to queue for execution
- executor, executes tasks from the queue and maintains a history of
when tasks are executed, sends mail on errors
- manager, interacts with the other programs esp. executor, Tk interface
available
- translator utility, translates crontab file to qsstab file with lapse
time period, weighting, nice/priority information

submitter checks the history to see how much uptime has accumulated
since the last time a particular task was executed, and if the cum
uptime for the task exceeds the value in qsstab, the task is submitted
to the queue.

executor checks the queue for entries--queue entries contain shell
scripts which will execute the tasks with the job characteristics
specified in qsstab such as nice value and whether executor should wait
for the task to complete before executing the next task.

manager allows you to manipulate executor and submitter.  For example,
if you're about to do a demo for a customer it would be very bad to have
the system bogged down running "makewhatis" or something stupid like
that--it should be possible to temporarily pause executor and/or
"procrastinate" a task until later.  Also, you might want to run
executor in a "greedy" mode when you have some free time that you don't
have to use your computer--
there should also be some crontab entries to automatically switch into
and out of greedy mode during certain times.

translator is basically a setup utility for qss that can read crontab
files and generate a qsstab.  qsstab entries describe the max amount of
uptime that should accumulate before a task is submitted to the queue,
what nice/priority the job should be run at, if executor should wait for
the current task to complete before executing the next task, weightings
to possibly "cut in" in the queue before lower weighted jobs

The amount of time I have to devote to things like this is extremely
limited (my 1 assistant and I manage a ~150 node site, ~50 of which are
unix servers) so I plan to work in Tcl/Tk and possibly expect because I
am very familiar with these tools and should be able to develop fairly
quickly.  When the logic kinks are worked out etc., it should be fairly
easy for someone to convert it to binaries compiled with Tcl/Tk
libraries or even to C or C++ if they want.

I think the first piece to work on is the cumulative uptime counter.
I'll probably do some tcl hack and convert the logic to a small c
program.

--
"Jonathan F. Dill" (jonathan@carb.nist.gov)
http://www.umbi.umd.edu/~dill


-- 
To unsubscribe:
mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null