[OpenAFS] Re: [OpenAFS-devel] Selecting a configuration file format for OpenAFS Services

[u+openafsdev-t07O@chalmers.se]

Hello Jeffrey,

On Sat, May 16, 2009 at 12:33:07AM -0400, Jeffrey Altman wrote:
> The gatekeepers are opposed to the addition of new compile time
> options because it puts packagers in the position of determining what
> features administrators and end users are able to deploy without
> building from source.

Right.

> However, additional command-line parameters have
> their own complexity issues.  For example, the current fileserver
> command line has approximate forty options; many of which are no longer
> optional for reasonable deployment configurations.

> There are several proposals on the table for additional features that
> require new configuration capabilities.  I believe that it is time that
> OpenAFS adopt a configuration file format and library.

A separate configuratrion file is not the best solution for all cases
or for all administrators. Nevertheless it can be useful.

In my eyes a separate file containing the necessary configuration setting=
s
as command line arguments is no worse than a different syntax, without
imposing a need for extra efforts.

I would suggest to rely on a separate program to process a config file
with the syntax of your choice and produce command line options to give
to the binaries.

I suggest at the same time to deliberately make the syntax nearly
identical to the command line options one. Then the parsing program
will be trivial -- like "grep -v '^#'" -- and there will be no learning
threshold for maintaining the configuration in its "config file" form.

There will be also full backward compatibility with the existing
scripts and no need to modify the existing programs.

Rationale:

Going for a configuration file, you would need to either hardcode
its location (and probably choose different locations depending on the
platform-specific packaging, thus adding to the confusion of the admins)
and/or add a command line option to point out the file, which essentially
adds to the number of files to be taken care of:
1. the script starting the services must set this option
   to point to
2. another file which sets more options.

This can be expressed in two mostly equivalent ways:
A. <binary> -config <configfile>
B. OPTIONS=3D`cat <configfile>` && <binary> $OPTIONS

The second way does not need any new support in the <binary> nor
introduction of a new configuration syntax.

With other words, choosing the configuration file syntax to be like
 -<option> <value> ...
 -<option> <value> ...
 ...
gives you all the power wihout any modifications of the software
nor in the documentation.

In practice though I would do OPTIONS=3D`grep -v '^#' <configfile>`
to allow comments in the file, which is quite useful.

[As an example of an unfortunate switch to "configuration files" I would
name stunnel. Version 3 is very convenient when you generate options on
the fly, which is quite painful with version 4. Creation and cleanup of
temporary config files on demand is burdensome ans sometimes impossible,
f.i. if you do not have a writable file system at hand.

OpenAFS is hardly being used with volatile configurations but the general
point remains, an introduction of an explicit "config file syntax"
gives no direct advantage per se and postulates some efforts both in
development, learning and deployment.]

My 2 =F6re
Rune