MIR for collectd requires some guidance

[Clint Byrum]

Hi everyone,

So we've identified a real opportunity for monitoring on the UEC platform using collectd. Collectd is built around the idea of scalable data collection, and includes some attractive plugins such as querying libvirt and jmx directly, two essential things to have when trying to keep track of Eucalyptus and kvm virtual machines. Because we want to have UEC monitor itself and provide graphs by default, we need to have the solution for that in main.

In the process of looking at requesting that collectd be included in main, it has become clear that the package is somewhat massive in scope. The methodology is to write tiny C plugins around big C libraries that can then be used to pull data or push data.

At issue is the fact that collectd has a number of non-main dependencies, and I'm concerned that we may be over-burdening ourselves by adding so much to main. As it stands right now, the dependencies of collectd that are not in main are:

- libdbi0 has already been requested for MIR due to rrdtool's dependence on it
- libesmtp is used in the SMTP check plugin and is of a high quality, though does need to sync w/ Debian since recent seucurity updates were made.
- libganglia1 - Should also be evaluated for MIR status, but not the rest of ganglia. The build-deps for ganglia are all in main except libconfuse-dev
  - libconfuse-dev is a small library for config file handling and has a clean record for security thus far
- liboping - tiny C/C++ library for wrapping ping functionality, no open security issues
- yajl - a fast library for doing json parsing.

The biggest concern is libganglia. Ganglia is another data collection/monitoring solution, a rather massive one at that. libganglia is used by collectd to run ganglia plugins, allowing collectd to use ganglia plugins unmodified, which is crucial in many environments for migrating away from ganglia. Its also important because Eucalyptus currently publishes ganglia plugins.

So there are a few ways we can approach this:

* Just include all of that stuff in main, thus increasing our burden of security maintenance and package support
* Split the package into a collectd-core that has just the stuff a user would normally need for use w/ collectd, and leave the rest in universe, thus introducing a delta from debian requiring merging with every release.
* Drop functionality from the package, thus disappointing some users who will then point at the universe packages and wonder why we removed functionality from a perfectly good set of packages.

I'm asking for guidance, because I don't want to overburden the MIR approval team with all of these libraries, if its perfectly acceptable to just split the package and deal with the merge burden going forward. I don't think it is acceptable at all to drop the functionality from the universe package.

Thanks!