[OpenAFS] Re: Thinking about a different way to distribute configuration.

[Russ Allbery]

David Boyes <dboyes@sinenomine.net> writes:
> On 5/17/09 2:08 PM, "Russ Allbery" <rra@stanford.edu> wrote:

>> A stateless file or database server?  I think you should think about
>> that concept a little bit longer.  :)
>
> Why? If the data it serves is on a SAN or otherwise connectable
> storage, why should the physical server handling the information be
> somehow special if it gets the same address and configuration
> information?

So put your configuration file on the SAN.

Keeping configuration files in sync across multiple nodes is really
basic large site systems administration, has to be solved for many
different applications, and is a *solved problem* using many different
techniques and methods appropriate to each site.  OpenAFS will benefit
itself the most if it works seamlessly with those existing systems by
behaving like a standard application.  Introducing a configuration
server that's unique to OpenAFS adds pain and complexity.

bosserver and the need to start AFS daemons in a different way than one
normally starts system daemons is *already* a trouble spot in the
learning curve for people who are experienced with systems
administration but new to AFS.  Adding another unique solution to a
common problem is going down exactly the wrong path, and with a lot less
justification than bosserver has.

Please do not try to make AFS special.  Running AFS daemons should not
be special.  Insofar as AFS looks just like any other system service
that people are already running, AFS benefits.

Please also do not try to put the kitchen sink into AFS.  That's a
direction from which we're slowly unwinding now that many of the things
AFS had to solve for itself are now solved problems elsewhere.  AFS does
not provide its own time server any more, or its own login utilities.
AFS should not provide its own configuration management system.  I want
to use my configuration management system to do configuration
management, not my distributed file system.  If you want to do
large-scale seamless configuration management, use Puppet, don't invent
a half-assed version of Puppet and embed it in AFS.

upserver/upclient are already borderline, but they are, in the current
KeyFile system, extremely useful in the specific case of rekeying an AFS
cell and they're ignorable if you have a better configuration
distribution method.  Changing AFS daemons to use an AFS-specific
configuration service would not be.

> No, it's not hard in an individual case, but the documentation can't
> keep up with current development as it is, so why should we
> deliberately decide to make that job harder?

Supporting configuration options plus a configuration file does not make
documentation appreciably harder.  Describing that in the documentation
is easy.  That's not the area where documentation is difficult.

> Also, consider the new guy. You and (maybe) I know when to use what,
> but how could someone facing this for the first time? How are you
> planning to explain that you can override option A from the command
> line but not option B? How could someone tell w/o referring to the
> docs?  Which you would have to update?

I believe you are exaggering this problem beyond the point of
reasonableness.

> Which IMHO would argue that there needs to be exactly ONE command line
> argument -- the location of the config file.

No.  This is exactly the behavior that constantly annoys me with
Kerberos where many things have to go into krb5.conf and you have to
duplicate krb5.conf and set an environment variable to get different
behavior.  It's understandable for Kerberos where the configuration is
for an underlying library and there's no clear way to tie into the
command line, but that loss of convenience in AFS where we can easily do
better would be a disservice to our users.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>