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

[Jeffrey Altman]

u+openafsdev-t07O@chalmers.se wrote:

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

No one has suggested that we are getting rid of the existing
command-line interface

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

There are several problems with using the command line:

1. If all you are doing is setting a single value such as
   "rxmaxmtu=1200", that is conveniently represented on the command
   line.  However, if you need to represent a complex data structure
   such as a multi-dimensional table using the command line is very
   user unfriendly and error prone.

2. On some systems the length of the command line is limited in length.
   As a result it becomes impossible to configure everything via the
   command line.  [On some systems that might be considered for
   future support there is no command line at all.]

3. The usage model is different.  With a command line all options
   that are specified must be understood or the application is supposed
   to fail.  With a configuration file, the contents of the
   configuration are polled.  Unrecognized options are silently
   ignored.  This permits a single configuration file to be used
   with multiple versions / builds some of which might contain
   experimental features that are being tested.

4. Adding each and every configuration option to the command line
   is user unfriendly.  There are literally hundreds of compile time
   values (most not configurable without a source code editor) that
   could be exposed for run time configuration.  This would permit
   a wide range of values to be altered easily in order to tune the
   behavior of the AFS service to specific environments.  Why should
   the absolute number of client hosts be hard coded to an arbitrary
   value picked in the early 90s?  Why should the callback expiration
   behaviors (a complex table) be restricted to an arbitrary set?

> 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.

This assumes that there is an external program that can be used to
wrap.  This assumption is not going to be valid in all environments.

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

There is no need for backward compatibility.  We are not removing the
existing command line options.  We are also not ruling out adding
new ones as they are appropriate.

> Rationale:
> 
> Going for a configuration file, you would need to either hardcode
> its location 

All of the OpenAFS services and clients already have configuration
files with well-known locations.

> [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.]

I believe I have given reasons why configuration files are a useful
addition.

Jeffrey Altman