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

[David Boyes]

On 5/17/09 5:25 PM, "Russ Allbery" <rra@stanford.edu> wrote:

> David Boyes <dboyes@sinenomine.net> writes:

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

Wait a second: I think I see the disconnect here. I don't want the
configuration service to be unique to AFS. I originally said "a"
configuration service. That could be DHCP options or TFTP or something
similar or whatever you choose. You can use Puppet if you want; I just
object to assuming that local files are the only way.

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

Agreed, insofar as I dislike local config files and think there ought to be
a better way.=20

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

See above.=20

>> 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?
>=20
> I believe you are exaggering this problem beyond the point of
> reasonableness.

Considering I've encountered this kind of question about AFS twice in the
last week, once in a non-English language where there ARE no docs for the
person to consult, I tend to disagree. I see situations like this fairly
often. YMMV, but I would assert that there is a lot more confusion about
this topic out there than you think.

>> Which IMHO would argue that there needs to be exactly ONE command line
>> argument -- the location of the config file.
>=20
> 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.

I guess this doesn't annoy me as much as it does you. I don't find it
difficult, and I long ago automated that sort of thing with Kerberos so it
doesn't occur to me that it would annoy someone. I find symbolic references
to configuration files a rather forward-looking idea, myself -- someone
finally learned the lessons from OS/360 about not doing data binding inside
applications.=20

I suspect we're disagreeing more on what "better" means here than anything
else. I find most configuration files incredibly crude and static. There ar=
e
other ways to think about this, and much of the current command line option=
s
are there to cope with the fact that there is no self-tuning capability in
AFS. If I were developing additions, I'd be looking to eliminate that
problem, rather than finding new ways to express a lot of static
limitations. Since we're not talking about that, and we're clearly not
connecting on any useful conversation here, I guess we're stuck with config
files, and so it goes.