[collectd] "Redesign" of the Debian collectd package

[Sebastian Harl]

Hi everybody,

This is a follow-up to Debian bug report [bts495936] and to other people
interested in that issue. Below, you'll find a summary of the changes, I
intend to implement in the Debian packaging of collectd. I'd be really
happy about feedback about that (even if it's just a short "ack" [on
IRC] ;-)). If I do not get any feedback within the next few days, I'll
assume that nobody has any major objections ;-)

The following main issues are supposed to be tackled:

 * Get rid of the dependency on librrd.

 * Make it easy to introduce custom configurations.

 * Provide reasonable defaults for less experienced users.

 * Be scalable (small as well as large setups should be equally simple
   to set up)

This is what I'm planning to do:

 * Introduce a new binary package "collectd-core":
   This package ships the daemon as well as all plugins and the init
   script. *All* plugin dependencies are suggested by that package (i.e.
   not installed by default by any package managers, unless it's
   configured to do so). The daemon will be enabled by default (in the
   init script) but refuse to start, if /etc/collectd/collectd.conf (or
   whatever has been configured in /etc/default/collectd) is not
   available - to not break the package installation in that case, a
   warning will be printed only but the script will not return with an
   error status. I'm a bit uncertain about that but imho, it's the most
   sensible behavior and I think there are other services in Debian that
   behave the same way. The package ships a couple of sample
   configurations in /usr/share/doc/.

 * The collectd package mostly provides the configuration. I'm thinking
   about disabling a few more plugins by default. It's your chance now
   to speak up if you have any preferences in that regard. By default,
   no output plugin will be enabled but a (medium-priority [*]) debconf
   question will make it possible to chose (this includes preceeding)
   zero or more plugins and, possibly, specify the most important config
   options of the selected plugins (low-priority questions). The
   specified configuration will be created as separate files (one for
   each specified plugin) in /etc/collectd/collectd.conf.d/ which will
   be included by /etc/collectd/collectd.conf. Of course, this will
   still have to make sure that any existing (or modified) configuration
   does not get overwritten -- since debconf will not handle all config
   option, changes to those files *must* be supported. I'm not entirely
   sure yet, how to solve that - any input would be very appreciated.
   One approach might be to modify the *options* of the config
   parameters supported by the package using sed or similar -- thus
   leaving all other options untouched. This package will recommend
   *all* plugin dependencies.

The "collectd-core" package will make it possible to build custom
packages on top of that, which provide a custom configuration and depend
on the appropriate libraries required by that configuration. That
package would have to depend on "collectd-core" and conflict / replace /
provide "collectd". Imho, this should be a fairly nice approach for
large (homogeneous as well as heterogeneous) setups (which, I suppose,
usually maintain a custom repository anyway).

Still, the "collectd" binary package will make it easy for novice users
to get started and -- by letting the user preseed the most important
config options through debconf -- should also provide a fairly nice way
to setup medium sized setups, thus providing an, imho, nicely scalable
solution.

I hope this handles all issues that have been raised by various people
in the discussions about this topic. Please tell me, if I'm missing some
(important) point.

There have been some requests to enable a network client sending to
multicast by default. I don't think that's a good idea, though, since it
would expose all values to "the world" by default. So, this would have
to be done in a separate package specifically created for that purpose
which does not make sense imho.

Possible *future* extensions (some random ideas):

 * Provide some helper script to ease the creation of custom packages
   (by letting the user specify a list of plugins and creating, e.g.,
   the appropriate dependencies from that).

 * Patch collectd to list the required deps if loading a plugin fails.

 * Something like Apache's a2enmod / a2dismod to enable / disable
   plugins through symlinks from /etc/collectd/plugins.enabled/ to
   /etc/collectd/plugins.available. I'm not really sure if a user would
   benefit from that, though, since the configuration would be split up
   in *lots* of different parts (89 as of collectd 4.8).

 * Provide even fancier ways to configure collectd. That's something
   that should be done upstream though (and possibly include hooks to do
   distribution-specific stuff like determining dependencies, etc.).

Further suggestions and comments are very appreciated!

Cheers,
Sebastian

[bts495936] <http://bugs.debian.org/495936>

[*] What is the default debconf priority? That should be a reasonable
    priority for that question as well.

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090930/a00b74e2/attachment.pgp