(changing the subject line so as to not hijack Jeff's config file question...)
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? All I care about is whether the server can connect to the appropriate resources. I don't store data in the server image, and I don't store configuration information in the server image. I get that from outside, which lets me clone the things ad nauseum. Perhaps we're using different definitions of stateless. >> Technically, you *can*, but the point is more along the line of >> addressing complexity. One of the major complaints about AFS is the >> additional complexity of managing it. If you have both command line >> AND config file, which do you use, and how do you explain to a newbie >> where to look? Having one or the other and clearly deprecating one is >> both less complex to manage and document. Remember, you have to >> document both if you have both. Why make more work for yourself? > > This is not hard. Seriously, just about everything else already works > this way, and the additional flexibility is incredibly useful in a lot > of real-life situations. 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? 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 agree with you insofar as it's handy to be able to quickly flip a option on the command line. I don't think it's good configuration management policy overall, though. It introduces a whole bunch of "A not B" problems, and makes it even harder to explain the logic of how to configure this beast than it already is. >> Also, is it any more complicated to modify a file and restart than >> restart with a very long command string? I don't think so. > > If you have a configuration file, why do you have a very long command > string? A configuration file means that the command string can be used > just for overrides. Which IMHO would argue that there needs to be exactly ONE command line argument -- the location of the config file. In that case, you have a consistent method of supplying the information, it can be arbitrarily modified for different cases (and you can have as many as you like), and the override method is straightforward for normal operations *and* for exception cases. Permitting the existing command line arguments for backward compatibility is good, but there needs to be a direction toward one consistent way to do it that subsumes the "old way" over time. -- db _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
