ideal config management framework [was: CPU Frequency Scaling]

[Davide Bolcioni]

Thomas M Steenholdt wrote:

> Also - Think of the additional error scenarios when init is gconf'ed. 
> The same complexity is added for everything else that adopts a registry 
> based configuration engine (since that engine has to be operational for 
> it to work in the first place) but may not be quite as aparrent.

As I suggested in another message in the original thread, if this is 
changed, i.e. everything adopts a registry-based configuration *if
one is found* but happily reads plain old configuration files from
/etc if not, this problem can be made less aggravating.

Personally, a scheme where (a) if the registry or policy daemon is not
operational it is supplemented by the configuration in /etc, and (b)
said configuration *overrides* unconditionally whatever the registry or
policy daemon spits out, would offer the right mix of safety and
functionality to give it a try on a non-production host, which seems the
sweet spot for Fedora. The scheme might get fancy and differentiate
between /etc/foo.conf which overrides unconditionally and
/etc/fallback/foo.conf which is read if the registry or policy daemon is
not available (and possibly overridden shortly thereafter).

For production use, however, the registry or policy daemon *must*
preserve comments and be manageable using whatever version control is in
use at a site (not everybody uses CVS or SVN); very often, there is a
reason behind setting something in a configuration and having to record
it separately is just one of the many shortcomings of registry-based
approaches.

Just my $0.02,
Davide Bolcioni
-- 
There is no place like /home.