On 5/17/09 5:25 PM, "Russ Allbery" <[email protected]> wrote:
> David Boyes <[email protected]> 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. > 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. >> 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. 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 applications. I suspect we're disagreeing more on what "better" means here than anything else. I find most configuration files incredibly crude and static. There are other ways to think about this, and much of the current command line options 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. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
