[collectd] Bug#495936: "Redesign" of the Debian collectd package

[XANi]

On 2009-10-05, at 23:50:17
Sebastian Harl <sh at tokkee.org> wrote:

> Hi Mariusz,
> 
> On Mon, Oct 05, 2009 at 11:35:41PM +0200, XANi wrote:
> > >on 2009-10-05 at 23:27:14
> > >Sebastian Harl <sh at tokkee.org> wrote:
> > > On Thu, Oct 01, 2009 at 09:57:47AM +0200, Raimund Sacherer wrote:
> > > > * About the enPlugin disPlugin, i do not think the user will
> > > > have a lot of benefit here.
> > > >
> > > > It's great if there are a bunch of plugins which do not really
> > > > need configuration, if a (very) few packages need them it's ok,
> > > > but if you *need* to configure every plugin it would be a little
> > > > configuration nightmare.
> > > 
> > > That's what I fear as well. So, I guess, I'll just drop that
> > > idea ;-) It probably makes much more sense to work on some nifty
> > > configuration tool upstream but not even that might be of much
> > > benefit (especially when compared to the required efforts) …
> > Hmm maybe make 4 confing files:
> > * Global (Interval, basedir, plugindir TypesDB etc).
> > * Input plugins
> > * Output plugins (rrdtool, csv etc.)
> > * Filters
> 
> What about plugins that can be put into more than one category? E.g.,
> the "network" plugin is an input and output plugin.
>
> > Then for example Admin could use same output plugin config for all
> > nodes and tweak others per-node.
> 
> I'm not sure if admins, in general, would really benefit from that. In
> most cases, the admins will have to adopt the config anyway, so they
> won't benefit from a rather general split like that (imho).
Yeah I guess most ppl won't use it.... guess we're stuck with One Big
File then ;]. Tho some kind of autodetect mechanism would be nice (like
if u have that lib turn on that plugin) but then it isn't probably
worth it because enabling right pligins is 1 min of editing anyway