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

[David Boyes]

(changing the subject line so as to not hijack Jeff's config file
question...)

On 5/17/09 2:08 PM, "Russ Allbery" <rra@stanford.edu> 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, wh=
y
should the physical server handling the information be somehow special if i=
t
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 th=
e
server image. I get that from outside, which lets me clone the things ad
nauseum.=20

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?
>=20
> 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 u=
p
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 polic=
y
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.
>=20
> 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 th=
e
override method is straightforward for normal operations *and* for exceptio=
n
cases.=20

Permitting the existing command line arguments for backward compatibility i=
s
good, but there needs to be a direction toward one consistent way to do it
that subsumes the "old way" over time.

-- db