Re: Configuration frontend
>>>>> "RGR" == Richard G Roberto <robertor@typhoon.co.jp> writes:
RGR> This sounds similar in principal to what I've been proposing
RGR> for almost two years on this topic (even before this list was
RGR> created).
I'm glad someone else also sees some sense in this approach; I was
starting to wonder :)
RGR> Can this be re-worded into multiple phases that we
RGR> can start refining in discussion?
How about this - it isn't particularly well fleshed out, but I think
it touches on most of the high points.
1. implement a mechanism to replace all config queries from
packages.
Status: done (modulo more stringent error checking in the script)
Visible effect: zip
Benefits: provides the important first step in abstracton.
1.x. (optional) implement alternative front ends for user
interaction
Status: not started
Visible effect: looks prettier
Benefits: none, except to dribbling idiots that insist on having a
colourful configuration phase which sucks their CPU dry. This doesn't
actually make the configuration any easier or add any functionality.
2. add some useful functionality, such as question priorities and
defaults
Status: well, we have a couple of ideas on what useful functionality
we would like to see...
Visible effect: depends on exactly what is implemented, but the two
above will allow the option of trimming down configuration stages, at
minimum.
Benefits: aside from the obvious, this is the first proof of concept
phase. If this yields tangible benefits, then it can be floated as a
serious proposal for maintainer comment.
3. implement alternative backends to store configuration data.
Status: none to speak of
Visible effect: how far can we take it? Possibly to completely hands
free installation, if we can use DHCP to boot a cluster and some kind
of auto-discovery method to find the config db. In real terms,
simplifying installation down to configuring the network, apt'ing a
local meta-package, and pointing the configuration engine to a local
config db.
4. less is more. Once crude hacks have been removed from package
configuration, we can look at more elegant ways of doing what we need
to. One example is centrally distributing not merely single items of
configuration, but serving out config files en masse.
Status: pipe dream
Visible effect: probably nothing
Benefits: obviously depends on exactly what we wind up doing. With
regard to variable substitution in conffiles, if an item of
configuration data is used only by one package, there is little point
in breaking it up into pieces, since they aren't likely to have any
semantic value on their own. This will save having to write additional
code and sanity checking for each individual config file that is
shipped.
RGR> Even if this bit is totally transparent to the way it
RGR> works now, we'll have achieved getting the abstraction in
RGR> there to work the other phases. Can this be as simple as
RGR> having an intermediate script simply take questions from a
RGR> package installation script, present them to the user, get
RGR> the user's response(s), and provide the answers to the
RGR> package installation script?
Yes, I've already written and posted a sample implementation of
this.
RGR> Once that's done, we'll have something to show the other
RGR> developers. It would of course be a good idea to fully flesh
RGR> out the other phases so we can decribe the full project. It
RGR> may be difficult to get buy in from people if all we had was
RGR> this first bit and a bunch of loose ideas about what to do
RGR> next.
Bah, humbug :)
m.
Reply to: