On Tue, 27 Apr 2004 09:15:09 -0600
Jim Bernard <jbernard@mines.edu> wrote:

>   But I'd much rather not have to specify sequence numbers for the tasks
> (and I'm not fond of the resulting clutter).  It means you have to examine
> the sequence numbers carefully to determine the actual sequence of tasks,
> rather than having it presented to you in some obvious way by the layout
> of the file(s).

I added a '-l' option to the script that shows you the sequence that will be
used.  For example:

[dawn jmmv] $ ./run-parts.sh -c ./test.conf -l -s daily test.d 
-1 test.d/header
1000 test.d/s3
2000 test.d/s2
3000 test.d/s1

> And you have to specify sequence numbers for all of the
> tasks, even though the sequence doesn't matter for most of them.

The sequence is given by /etc/defaults/periodic.conf, and I doubt anybody
will want to change it.  Maybe you'll want to change one or two numbers
(after you move tasks around), but surely not all.

> Further,
> if you change a task from daily to weekly (e.g.), a completely new set of
> sequence numbers becomes relevant to it.  Switching back and forth (for
> those who have trouble making up their minds) then becomes burdensome.

It is not much of a problem.  Tasks can have the same step number (they will
be sorted alphabetically).  So if you move, for example, the locate rebuilddb
from weekly to daily, you shouldn't care at all about numbers; you might, of
course, change the one associated to rebuilddb so that it gets run as the first
thing, by giving it a 0.

>   Now doing away with the sequence numbers seems to make it difficult to
> have system (default) updates automatically add new tasks without the need
> for user intervention, since it would seem to imply that the actual sequence
> of tasks must be specified by the order of lines in a single file, which
> would have to be the local conf file if the user wants to make any changes
> from the default.  I see a few options to address this, none of them without
> fault:
> 
>   1 Use rcorder.  This makes the sequencing more difficult to discover,
>     but it's easy to get interdependent tasks in the right order.  It also
>     makes it necessary to modify existing scripts (or copies thereof) to
>     make changes in the sequencing.  Since the order doesn't really matter
>     in most cases, this is overkill.  But for the same reason, maybe it
>     doesn't matter much if it's hard to discover the order and hard to
>     change the default order.

rcorder was the initial proposal.  AFAICT, nobody liked it because it can make
output unconsistent across machines.

Having numbers provides you a very concrete sorting, and if the defaults file
is the same on all the machines you manage, the output of the periodic scripts
should match.

>   2 Live with the fact that the user has to copy the entire defaults file
>     in order to make changes, and the local conf file won't be automatically
>     updated if there are new tasks added to the defaults file.  etcupdate
>     can help with this, but it's still an annoying issue.

This is not needed at all...  you just override values in the local configuration
file (usually of the form: taskN=period), and shouldn't care about the defaults.

>   3 Add a configuration tool that would present the user with lines whose
>     sequence represents the execution sequence, but that translates any
>     user changes into some appropriate set of local conf-file bits in
>     whatever format is chosen.  The underlying implementation then becomes
>     unimportant (sequence numbers would be OK) and is free to change later.
>     But it adds another layer that removes the user from what's really going
>     on, and adds complexity and opportunity for failure due to bugs in the
>     config tool.
> 
>   4 Have the super script (run-parts or whatever) merge the lists of tasks,
>     so that any that appear in the local conf file cause deactivation of
>     any specifications in the defaults file.  This way, new tasks that
>     show up in the defaults file will be run automatically.  To give the
>     user some control over sequencing, here are some possibilities:
> 
>       a Make the local conf file have "before" and "after" sections, whose
>         tasks are entirely executed before and after the tasks in the defaults
>         file.  If the sequence of tasks in the defaults file needs to be
>         changed beyond movement of a single task to the before or after
>         sections, or a local task needs to be inserted between two tasks in
>         the defaults file, it could be necessary to copy a substantial chunk
>         of the defaults file to the local conf file.
> 
>       b Provide "before" and "after" keywords to allow arbitrary insertion
>         by the user.  In the absence of those, the tasks would be run in
>         script order, as determined by some merger of the defaults file and
>         the local conf file.  E.g.,
> 
>           run task3 weekly
>           run task1 daily before task5
>           run task6 daily after task2
> 
>         This is somewhat like using rcorder, but control over the sequencing
>         is moved to the conf file, so that changes to the default sequencing
>         don't require changes to the scripts.  And in most cases the sequence
>         is simply that given in the merged conf file(s), with no need to
>         specify it explicitly by keyword.  But the ordering can become less
>         visually obvious than with a strictly line-ordered sequence, and it
>         is possible to specify inconsistent ordering requirements.  This one
>         could also include 4a.
> 
>       c For those few tasks for which sequencing is important, combine the
>         scripts into a single script or use a wrapper script, rather than
>         the individual scripts to run them.  In most such cases, it would be
>         necessary to keep them together anyway, in the sense that changing
>         one of them from daily to weekly (e.g.) would require changing them
>         all and keeping the same order.  But this does reduce flexibility.
>         This one could usefully include 4a.

When I first splitted the periodic scripts into individual chunks, I found none
of these situations.  Each task is self-contained (or can be made easily).

>   5 Attach the sequence numbers to the names of the scripts (or links to
>     the scripts), letting the config file merely specify what is to run and
>     how frequently.  This has most of the disadvantages of having the sequence
>     numbers in the config files, though they'll be automatically presented
>     in order by ls.
> 
>   I would lean toward 4b or 2, and I could live with 4a, 4c, or 1.  I don't
> like sequence numbers in any form, including 5, and I'd much prefer to
> avoid the need to use a config tool (3), beyond a simple text editor.

Cheers

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/