[OpenAFS] Re: [OpenAFS-devel] Selecting a configuration file
format for OpenAFS Services
Sat, 16 May 2009 11:26:03 -0400
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.
>> 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
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.