Will this be the packaging for collectd 4.8? In following with the apache example, maybe deliver /etc/collectd/collect.conf.example, and have a debconf question to copy it into place?
Since the default apt behavior is to install-recommends, imo, collectd-rrd output would be a useful recommends (as opposed to suggests) to keep with the current usability. And in that case, the collectd.conf.example could still store its data in the rrd format. Any thoughts? --Joe ----- Original Message ----- From: Sebastian Harl <[email protected]> To: [email protected] <[email protected]>; Marc Fargas <[email protected]>; Moore, Joe; Raimund Sacherer <[email protected]>; Joey Hess <[email protected]>; Ivan Shmakov <[email protected]>; Marco d'Itri <[email protected]> Cc: [email protected] <[email protected]> Sent: Wed Sep 30 11:37:48 2009 Subject: "Redesign" of the Debian collectd package 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 _______________________________________________ collectd mailing list [email protected] http://mailman.verplant.org/listinfo/collectd
