Comment # 1
on bug 1136
from Ken McDonell
G'day Frank.
Just adding some thoughts so they don't get lost ...
- changing metadata between archives in a multi-archive context would involve a
significant change ... at the moment there is only one copy of the metadata and
it is cross linked for access via context and via pmid ... without the correct
metadata libpcp cannot even decode the pmResult, much less do interpolation ...
this sounds like per-archive metadata in libpcp or a 2-level cache of metadata
(global and per-archive for things that are different)
- clients typically fetch the metadata once and then use it over and over to
decode pmResults on their side of the PMAPI ... this pretty much means any
changes in metadata would have to be entirely encapsulated within libpcp
- it is not just PM_TYPE that is potentially in play ... I've long wanted
pmlogreduce to do statistical rate reduction on counters to handle wraps and
short gaps (around <mark> records) ... this would change the metric units&scale
from, for example, BYTES to BYTES/SEC and further complicate the on-the-fly
interpolation and pmResult construction (I think this makes the pmlogrewrite to
"widen" the data type option a non-starter)
- dealing with raw and rate converted values for the same metric across
different archives is doing my head in ... I don't even have the start of a
solution here because which ever semantics you choose to export above the
PMAPI, there is no robust algorithm to synthesize values for the periods where
the archive contains values according to the "other" semantics
- and the solution here has to work for both interpolate mode and
non-interpolate mode
This is not undoable, just not easy ... 8^)