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

[Jason Edgecombe]

Jeffrey Altman wrote:
> 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.
>   
I support the use of config files. Kerberos tends to follow the Windows 
INI config file syntax, and I think that would be a good choice for 
config formats. I'm not sure how well that format handles 
multi-dimensional options, though. How would that be encoded?

Given the OS limits on command-line lengths, I don't think it's 
technically feasible to require all options to be specified on the 
command line. I would propose that,  when appropriate, each config 
option could optionally be specified on the command line similar to ssh 
(i.e. ssh -o "option=value"). I also propose that every current 
command-line option be represented in the config file.

Thanks,
Jason