while our US colleagues are likely paralyzed from the annual Turkey
massacre :-) I was busy to do some cleanup and add some stuff to the
- moved the remaining arch dependant stuff from gmond to a header file
in libmetrics. Now gmond is purely generic. Libmetrics is still kind of
ugly. See the name of the new header file :-)
- added stubs for the following metrics to those archs that did not
have them: cpu_intr, cpu_sintr, bytes_in, bytes_out, pkts_in, pkts_out,
disk_total, disk_free, part_max_used. The dummy metrics are not
enabled, so nothing is actually changed for the reporting. The dummies
are all marked "FIXME", so people with some time at their hands could
try to fill them with content.
- took some real stuff for Darwin from Sebastian Hagedorn.
If we would make all mentioned metrics into core stuff, we would be
clean of the ifdefs except for HPUX (some obscure mem stuff that I am
responsible for, mem_[am,arm,vm,avm) and SOLARIS
We could kill the HPUX stuff (its mine) and I have no real opinion
about the SOLARIS data. The graphs do not look very interesting to me.
Sometimes, maybe, one just has to let go ...
But of course, that would bring some trouble with compatibility. As I
discovered, and Matt confirmed, the mcast channel does not really like
to deal with gmonds reporting different metrices. Similar for unicast.
So, how to solve that? Why don't we bring some system to our release
numbering scheme? We have "major.minor.sub", but we are not really
using it. My proposal would be:
- changes in "sub" are only bugfixes, tuning and "compatible" changes.
As a result, a change in "sub" would not cause trouble on the mcast
channel. New binaries would work with the same configuration files as
older binaries with same "major.minor". Just drop them in.
- changes in "minor" mean incompatibility. Either new metrices, or
different behavior, cool new config syntax. A new "minor" release would
mean that admins would have to upgrade all gmonds on their grids(s) to
keep the mcast channel happy.
- changes in "major" would mean real conceptual changes. Like the stuff
that Matt has been talking about for a while now.
What do you think? Matt?
If we follow this scheme, we could declare 2.5.7 the "last" 2.5 cut
and call the next release 2.6. I would activate the dummies for 2.6.
Or we do 2.5.8 as the final 2.5 release (I would revert the cpu_wio
changes to the 2.5.7 state to ensure compatibility) and follow up with
2.6 as above.
If we don't implement this change, I would opt for going ahead with
2.5.8 as it is now, activating the dummies in 2.5.9 and live with the
email: k n o b i AT knobisoft DOT de