[OpenAFS] Re: Thinking about a different way to distribute
Sun, 17 May 2009 18:19:57 -0400
On 5/17/09 5:25 PM, "Russ Allbery" <email@example.com> wrote:
> David Boyes <firstname.lastname@example.org> 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.
>> 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
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.
> 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
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=
other ways to think about this, and much of the current command line option=
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.