Ouch. Sorry had not considered this. I'll undo those changes and leave
the hinv metrics alone.
Special cases in QA is better than special cases in pmlogextract.
We probably need to think more carefully about how metadata changes
could be made in general for established metrics ... at some point
someone will want to promote a metric from 32-bit to 64-bit, or Bytes to
Mbytes, or ... so the problem is a latent one that will come back at
some point in the future.
On Mon, 2011-05-09 at 13:28 +1000, Nathan Scott wrote:
> Hi Ken,
> ----- Original Message -----
> > ...
> > commit 3445cedfe73186a6e7e43b7b630c00442ccb5bd9
> > Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> > Date: Fri May 6 10:17:43 2011 +1000
> > hinv.nXXX metrics - make metadata consistent
> > Across all the platform PMDAs, the semantics of the hinv.ncpu,
> > hinv.ndisk,
> > etc. metrics should be consistent. You can toss a coin and decide
> > their units should be "none" or "count" ... I decided "none" and made
> > it so everywhere.
> Hmm. I think this might cause a fair bit of pain for those of us
> with many hundreds of machines whose daily logs will not merge
> successfully after the upgrade ... ? Is there any chance we could
> do something sneaky, like make pmlogextract able to cope with this
> pmDesc difference and just pick one?