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< -- o...@leeloo:~/collectd $ grep vserver src/collectd.conf.in #...@build_plugin_vserver_true@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/
signature.asc
Description: Digital signature
_______________________________________________ collectd mailing list [email protected] http://mailman.verplant.org/listinfo/collectd
