[collectd] Adding new DS definitions to existing plugins

[Florian Forster]

Hi Nic,

On Wed, Jan 24, 2007 at 10:58:34AM +1300, Nic Bellamy wrote:
> I'd like to submit these patches when they're ready, but would be 
> interested in any advice regarding how best to handle backwards 
> compatibility issues. I couldn't find anything on the website containing 
> policies about this kind of thing - can anyone fill me in?

We (try to) garuantee backward-compatibility for all versions of the
same _major_ version (i. e. between minor versions) and backward- and
forward-compatibility for all versions of the same _minor_ version (i.
e. between patch releases). Compatibility is defined from a user's point
of view, i. e. the config-file and the RRD-files must still work with a
newer version. Internal changes, e. g. the plugin interface, are _not_
included in this definition and may (and have) change between minor
versions.

> I've whipped up a "works for me" patch for src/cpu.c that adds irq +
> softirq DS definitions to ds_defs[], and updates cpu_read/cpu_submit
> to handle the extra data,

I'm in the process of writing a new major version, collectd 4. It is no
problem at all to include that change there, though I considering to
pull the RRD-file appart and use one RRD-file for each counter type.
This offers a lot more flexibility over the RRD-file as it is. I
originally decided against doing that because I thought that now
breaking backwards compatibility where it can be avoided might be a good
idea, but if the datasources change anyway I might as well do that.

If this patch should be accepted into the collectd 3 line then it's
necessary that the default behavior doesn't change. You could use the
alternative RRD-file-layout when configured to do so or simply use
seperate RRD-files and do some trickery at graph-generation-time. I
think the second option would be preferable for most users.

> and am planning to do a similar thing to src/load.c to keep track of
> IRQ counts and context switches (since it's per-system, not per-cpu
> counts, src/load.c makes sense to me).

I'd put that in a seperate plugin. I'm unsure if it's better to put IRQ-
counts and context switches (and possibly forkrate) into one plugin
(since it can all be read from `/proc/stat' under Linux) or if it'd be
preferable to use one plugin for each. The former would be easier to
implement while the latter might be more overhead but would fit the
overall design better. Any opinions?

Sorry for all the terrible mistakes I no doubt have made somewhere in
this mail, but I'm on my way to bed and can really use some sleep ;)

Regards,
-octo
-- 
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/20070123/f04eae36/attachment.pgp