David Boyes <[email protected]> writes: > On 5/17/09 2:08 PM, "Russ Allbery" <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
