[MIR] collectd

Why does collectd want to be in main? What's the rationale/blueprint for it?

Its part of the monitoring improvements we've been working on:

https://launchpad.net/ubuntu/+spec/server-o-monitoring

collectd has been identified as a more scalable and flexible replacement for munin in larger environments.

This, as a daemon, should get a security review first.

- MIR for protobuf-c in bug 801735; but demoted by pitti. maybe he can explain
- hal has no chance into main again.
- MIR for liboping in bug 801774; demoted by pitti again.
- MIR for ganglia in bug 801615, deferred for 12.04

protobuf-c> I only demoted it because nothing in main needs it, so it appears on component-mismatches. It will just be re-promoted to main once there is a reverse dependency. So this is not a blocker. Same for oping. That's the reason why the MIR procedure says to only promote a package when it is seeded (which isn't appropriate for these two packages) or has rdepends. It won't stay in main for long if it is just promoted.

hal> Indeed, any hal usage needs to be ripped out of collectd.

As this is previously supported, and will be supported for the LTS; are there any objects if it ships in main for Oneiric in it's current state?

Thanks.

David, ganglia has to be done first, and it's deferred until 12.04. Can collectd work well without it (i.e. without the gmond plugin)? And this would still need a security review.

I thought this comment from pitti: "hal> Indeed, any hal usage needs to be ripped out of collectd" made this basically a non-starter. Also, I don't see where collectd was ever previously supported (checked 'main' on old-releases.ubuntu.com). Am I missing something?

I don't know what Dave meant about being previously supported. But I should have mentioned that the hal issue isn't a concern because hal is disabled during the build. i.e. it's already 'ripped out'.

Apologies, i miss-parsed comment #4.. I thought it was stating that it was previously demoted.. following now, apologies for the noise.

Dropping for Oneiric.

Thanks.

Before dependencies to this are often "just" to libcollectdclient1.
But then Recommends was still overloaded.

E.g.
libcollectdclient1 -> Recommends: collectd
collectd -> Depends: collectd-core (>= 5.9.2.g-1ubuntu5), collectd-core (<< 5.9.2.g-1ubuntu5.1~), libc6 (>= 2.14), librrd8 (>= 1.3.0)
Recommends: intel-cmt-cat (>= 3.2), libatasmart4 (>= 0.13), libbson-1.0-0 (>= 1.16.1), libc6 (>= 2.29), libcurl3-gnutls (>= 7.18.2-5), libdbi1 (>= 0.9.0), libesmtp6, libganglia1, libgcc-s1 (>= 3.0), libgcrypt20 (>= 1.8.0), libglib2.0-0 (>= 2.12.0), libgps26 (>= 3.3), libgrpc++1, libhiredis0.14 (>= 0.14.0), libi2c0 (>= 4.0), libip4tc2 (>= 1.8.3), libip6tc2 (>= 1.8.3), libldap-2.4-2 (>= 2.4.7), liblua5.3-0, libmemcached11, libmicrohttpd12 (>= 0.9.50), libmnl0 (>= 1.0.3-4~), libmodbus5 (>= 3.0.2), libmongoc-1.0-0 (>= 1.16.1), libmosquitto1 (>= 1.2), libmysqlclient21 (>= 8.0.11), libnotify4 (>= 0.7.0), libopenipmi0, liboping0 (>= 0.3.3), libowcapi-3.2-3 (>= 3.2p3+dfsg1), libpcap0.8 (>= 1.0.0), libperl5.30 (>= 5.30.0), libpq5, libprotobuf-c1 (>= 1.0.1), libprotobuf17, libqpid-proton11, librabbitmq4 (>= 0.6.0), librdkafka1 (>= 0.9.1), libriemann-client0 (>= 1.10.0), librrd8 (>= 1.4~rc2), librte-eal20.0 (>= 19.11), librte-ethdev20.0 (>= 19.11), libsensors5 (>= 1:3.5.0), libsnmp35 (>= 5.8+dfsg), libssl1.1 (>= 1.1.0), libstdc++6 (>= 5.2), libtokyotyrant3, libudev1 (>= 183), libvarnishapi2 (>= 6.1.0), libvirt0 (>= 1.2.11~rc1), libxenmisc4.11, libxml2 (>= 2.7.4), libyajl2 (>= 2.0.4), default-jre-headless

So yes, people "could" install it with few dependent packages, but generally since recommends are installed by default a lot will still be pulled in.

This now changed:
libcollectdclient1 as of 5.11.0-2 in groovy has only:
Depends: libc6 (>= 2.14), libgcrypt20 (>= 1.8.0)
Suggests: collectd

That opens up the chance to consider promoting only that client lib.
But so far the only package making use of that is freeradius and for now that could as well be a minor delta there.

My former comment should mean "this now seems doable" but we will need a Team that buys into it and is willing to own collectd. I have asked around a bit but the use cases were not convincing to anyone I asked.

That means, if we can find a decent use case for the overall ubuntu users, that convinces a team to step up owning the package. Then this MIR can be re-started.

I'd ask anyone who is "waiting" for this to outline what big benefit that would be.