Re: [Clockwork-developers] Kicking around some requirements

[Charles B. H. <br...@do...>]

----- Original Message -----
From: "Joel Loudermilk" <jo...@lo...>
To: <clo...@li...>
Sent: Monday, December 10, 2001 9:35 PM
Subject: [Clockwork-developers] Kicking around some requirements


> In doing a little research on the web by looking at commercial job
schedulers,
> it seems that there are very different approaches to the architecture of a
> scheduler. But before I started thinking about that too much, I wanted to
> build a list of the things I wanted to see in a scheduler.
>
> Here's what I came up with:

<Snip>

> If you've got any thoughts along this line, please post them. I'm sure
> we've all had enough experience with AutoSys to at least have an opinion
> on what's important and what's not.

I have a couple of requirements I thought I'd throw out to see what everyone
thinks:

1) Dynamic evaluation of schedule:  There should be a capability within the
scheduler to evaluate certain values dynamically.  In other words,
definitions of jobs could include, say, some variable, whose value would not
be evaluated until runtime.  Obviously, certain fields would need to be
exempt from dynamic evaluation: job name, start time, etc., but things such
as user name, executable locations, etc., should be able to be evaluated by
the scheduler at runtime.  This is one feature that Autosys doesn't seem to
have.  It does support dynamic evaluation of variables on the target system
(i.e., you can include an environment variable in the executable name, to be
expanded by the shell when the job is run), but not as such in the
scheduler.  I think this feature would be quite valuable to schedule
administrators.

2) An efficient way of entering schedule changes:  It seems to me that there
should not only be a way to edit jobs directly, through, say, a GUI, but
there should also be a command-line method for entering changes.  Further,
this command-line method should support some syntax for making *changes* to
an existing job, rather than just supporting the replacing of one job
definition with a new one.  Perhaps a declarative language somewhat like SQL
could be used to interactively make changes to and display information about
existing jobs.

3) An efficient way of designing schedules:  Autosys lacks (big-time) a way
to design a schedule, and then translate that design into something the
scheduler can take as input.  A GUI application, perhaps, could allow the
user the capability to graphically design a schedule, and could then export
the schedule in some sensible format.  Much of the tedious part of working
in SchedEx must be the dual maintenance of spreadsheets and the actual
schedule.  This might be a difficult application to write, and it should
likely be placed in the somewhat-distant future as compared to other pieces
of the scheduler, but I think it's important.

4) Truly dynamic data storage:  This probably means that we need to
implement the schedule in some sort of database, but we can't use anything
that (for example) requires a HUP to be sent to daemons when changes are
made.  Direct file-based I/O might be okay too, provided we're interested in
developing and maintaining that code as well.  If we choose a database, I
propose that we make a (possibly feeble) attempt to support more than one
database platform.  Depending on what database features we need to use (e.g.
triggers), we might lock out some database platforms, but even so, our
database interactions ought to be standards (ANSI SQL) compliant if
possible.

--
C. Brian Hill
br...@do...