Re: Configuration management, revision 3

[Martin Oldfield <m@mail.tc>]

>>>>> "Raul" == Raul Miller <rdm@test.legislate.com> writes:

    Raul> Martin Oldfield <m@mail.tc> wrote:
    R> Er, if you don't mind that you have a nondeterministic state
    R> machine (for example: all possible states exist in parallel)
    R> when you're describing the configuration for many machines.
    >>
    >> Is this the right way to think about it ? After all, every
    >> individual configuration must be deterministic, and if you
    >> conflate a whole bunch of configurations into one uberconfig,
    >> then you have to think how you're going to untangle them
    >> again. Do you have a concrete example in mind ?

    Raul> I was thinking of a global configuration for everyone, with
    Raul> local config information for specific machine parameters.
    Raul> Thus, if there's a yes/no question where yes implies one
    Raul> prompt and no implies another it is probably useful to be
    Raul> able to specify both the yes and no answers for the global
    Raul> case, providing reasonable defaults if the local machine
    Raul> would make the alternate choice.


    Raul> This shouldn't be all that complex to manage: for the most
    Raul> part packages are configured independent of each other.

I agree. In such cases you ignore the state machine and ask all the
possible questions, then dump those into the name:value pairs. I don't
know if people will want a tool for this, or if they'll prefer to
generate the name:value pairs by hand/script. 

Answering irrelevant questions isn't going to be intuitive to the
casual user, but I think that's inevitable. 

> If somebody is installing many machines and wants to answer all the
> questions (though I'm not sure this ever makes sense), then they can
> go through all the blocks and answer all the questions. Otherwise they
> just navigate the configuration system under the state machine's
> control.

Having read your message, I suspect that a more common use will be for
the package creator. He's hopefully even more au fait with the package
(!) and so should be able to handle this. I suppose this means that
you want default name:value pairs to be shipped with the package and
then installed into a local database with the package. Is there scope
for some baroque, cvslike (?), tagging system for different
configurations there I wonder ;*) More seriously I think an
inheritance hierarchy is a better model.

Cheers,
-- 
Martin Oldfield.


--  
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org