Re: Configuration files

On 4 Oct 2008, at 20:00, Narayan Desai <desai@...> wrote:

>   Paul> I think this is going in the right direction, but I still  
> think that
>   Paul> dealing with "files" as opaque objects is misleading - a  
> "file" is
>   Paul> rather an arbitrary unit - it is just a convenient way of  
> bundling
>   Paul> together some information - which may, or may not be  
> conceptually
>   Paul> related in configuration terms.
>
> I disagree. While I certainly agree that configuration files are a
> historical artifact, as opposed to some sort of platonic ideal, there
> are some really useful properties that configuration file-based
> statistics have that have not yet (to my knowledge) been implemented
> with a parameter-based statistics mechanisms (for lack of a better  
> term).
>
> Like it or not, configuration files are a unique formulation; this  
> means
> that a given change (or state) can be represented in a unique
> fashion.

You are picking a completely arbitrary level by talking about files. Why
not talk about bits on the disk if you want to use this argument -  
the same
is true there, and that actually makes a much better starting point  
if you
want to create a useful abstraction (see the comments Brandon made
about the registry etc).

> When you are dealing with a lower level formulation that takes
> a number of parameters into consideration, this representation will  
> vary
> based on personal style, preferences, and (likely) the important
> features of the problem at hand. Ergo, configuration for the same
> subsystem may be very different from site to site or system to system.
>
> Moreover, aggregating configuration parameters into file-based changes
> gives you an intuitive sense that measuring parameter change  
> transaction
> load does not. In short, you are looking at the results of parameter
> changes, not the parameter inputs. While you are correct that the
> parameter inputs are important, i think that analysis of the
> configuration file results yield far more intuitive insight than  
> viewing
> parameters.

I still don't see the difference between this and looking at the  
register allocations
in my compiled code. Why do I care what's in the files (except when  
something
goes wrong?)

> For example, Paul, do you have any sense for how many parameters there
> are in your LCFG parameter store that are defined for a client, but  
> not
> used in its configuration?

I'm not sure I understand what you mean by "used" - the configuration  
specifies what the
machine should look like and the system "makes it so". This process  
may involve
changing some parameters and not others, but they all "count" in the  
sense that
they are enforced as true statements about the machine - so they are  
all "used".

If course, if you include some "libraries" of configuration  
parameters for some
function, then not all of these may appear in the final profile (just  
as when you
link libc with your program).

> I think that it would take a fair amount of
> care to avoid defining these parameters for clients that do not  
> actually
> consume them. If a parameter change view is all that is reported, the
> parameter delta times number of clients product could vastly  
> inflate the
> amount of change being processed by the system.

It depends on what you are trying to measure .....

But I don't see why this is different from files? If I change the  
httpd.conf for
a machine which isn't running apache, have I changed the  
"configuration"?

> Even in the case where all parameters are sparsely defined (and hence
> consumed) this information isn't necessarily intuitively
> useful. Consider an event that results in a large number of changes  
> to a
> record-based file like /etc/passwd. The quantity of those events  
> aren't
> comparable to any other sorts of parameter changes elsewhere in the
> system. And so forth and so on..

Maybe we are interested in different things ...

Consider a password file which is made up of administrators and  
students and
generated by the config system ....

a) Someone changes the "class" of a machine so that the groups of  
administrators
allowed to log in to it change.

b) Someone else adds an administrator to one of these group.

c) Someone else removes a student.

How many "changes" is this? The config tool will perhaps only  
generate the password file once.
If I am only interested in the file, I see a whole load of entries  
changes, but I don't really know what
they are or why. Is this one change? or 100?

If you look at the reasons for the change, you see the three changes  
a,b and c. This certainly
seems more "intuitively useful" ?

> Configuration files are common aggregations that everyone already  
> pretty
> much understands.

Sorry. This may be true at the lowest possible level, but it that  
level of understanding
in not generally useful. I'm sorry to keep driving back at the  
programming analogy, but
I can certainly look at some object code and tell you what is number  
is going to be in
the registers at any one point - but that doesn't mean that I have  
any understanding
at all about what the programme does?

Similarly, I can look at look at the config file for firewall rules  
on one machine, but that
doesn't tell me much about the security of the network as a whole,  
unless I consider the
other machines and how they interact. The files defining the rules  
will be in several
different formats as well, depending on the type of system, and it is  
likely that there will
be several  rules which are redundant (if it has been created by hand)!

   Paul

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.