[collectd] Config changes

[Florian Forster]

Hi Mirko,

thanks for your comments :)

On Fri, Sep 18, 2009 at 12:39:38PM +0200, Mirko Buffoni wrote:
> I noticed that 'LoadPlugin vserver' directive is not present anymore
> in collectd.conf, though the plugin is compiled.

Weird. It should be included in the standard config file, though
disabled:
-- 8< --
 octo at leeloo:~/collectd $ grep vserver src/collectd.conf.in
 #@BUILD_PLUGIN_VSERVER_TRUE at LoadPlugin vserver
-- >8 --

> Couchdb is missing 'LoadPlugin couchdb' directive in collectd.conf
> header.

The “CouchDB” plugin has been renamed to “cURL-JSON” (due to the fact
that it can query other daemons, such as Hadoop, too). I see that the
example block is still named “couchdb” though. I've changed that to
“curl_json”. Thanks for noticing.

> Generated collectd.conf is missing additional parameter for dns
> 
> #<Plugin dns>
> #	SelectNumericQueryTypes true
> #</Plugin>

It's added, thanks :)

> #<Plugin http>
> #	URL "http://example.com/collectd-import"
> #	User "www-user"
> #	Password "secret"
> #</Plugin>
> 
> I cannot find which plugin is this for.  Leftover of write_http?

I think so, yes. I've removed it.

> This is a proposal.  I went through all plugins and created a
> different config file layout:
> 
> […]
>
> To me this has several advantages:  plugin classification allows me to
> better identify plugins based on their purpose, and also to deploy a
> rather standardized package with more or less plugins which can be
> installed separately together with their config file, in a separate
> package, when needed.

I have to admit such classifications usually annoy me, because I can't
see at once what's where. Also, it seems to be a natural law that the
category one look in at first is not the right category. [*]

> Of course the best would be to keep up-to-date the single
> configuration files, hopefully with a brief description at the top of
> the config file, and maybe with the part of the manual that summarize
> the parameters, as a quick reference, to avoid to go through the
> manual each time.

The problem I'm seeing here is that this is very hard to maintain.
Keeping 80+ files up to date and consistent with the manpage is a lot of
maintenance work Keeping 80+ files up to date and consistent with the
manpage is a lot of maintenance work for little extra comfort. And I
don't think the resulting inconsistencies will necessarily improve the
documentation.

The only way I could picture this was to centralize the information and
generate everything from this. Ideally, that place is the POD files from
which the manpages are generated. We could add a bunch or extra markup
and write scripts to generate the config snippets from that.

For example:
-- 8< --
=head2 Plugin C<csv>

=for comment BEGIN DESCRIPTION csv

The CSV plugin …

=for comment END DESCRIPTION csv

=for comment BEGIN SYNOPSIS csv

 LoadPlugin csv
 <Plugin csv>
   …
 </Plugin>

=for comment END SYNOPSIS csv

…
-- >8 --

Regards,
—octo

[*] Maybe categories have heard of Schrödinger? If something could be in
    two or more categories, it's undecided in which category it is until
    you look. And then it's in the/an other.
    <http://en.wikipedia.org/wiki/Quantum_superposition>
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090919/d4493e12/attachment.pgp