https://bugzilla.redhat.com/show_bug.cgi?id=1296750
--- Comment #8 from Ken McDonell <kenj@xxxxxxxxxxx> ---
Frank,
What you're proposing is a very important change to the design assumptions that
underpin pmFetch() and indeed the broader PCP architecture. Namely:
- archives and live sources should be semantically as close as we can make them
- one client can fetch different metrics at different points in time
- pmFetch() delivers a snapshot of metric values at a single point in time
- as a general rule temporal averaging (and rate conversion is one example of
this) should be a client-side function (to reduce complexity, state and
semantic uncertainty at pmcd)
I think the point of interp mode is to provide values at a point in time that
might be different to the sample times in the archive, which is subtly
different to your suggestion of "the client doesn't want to know the ebb and
flow of the actual underlying data".
Critically, interp.c has no visibility to the history of pmFetch() calls, it
operates on the state of the archive and the point in time for the current
pmFetch().
So, I'm loathe to push functionality into interp.c when I believe that
functionality is better done in the PMAPI client.
Note that all of this discussion is moot for non-counter metrics, so any
interp.c changes would have to work for a mixture of counter and non-counter
metrics in a pmFetch() and possibly different metric-instances appearing in
consecutive pmFetch() requests.
I can't see any way to overload the data continuity status in the result from
the current pmFetch().
I think I can implement a pmCheckContinuity (suggestions for a better name
would be appreciated) that takes two timestamps (as returned by pmFetch) and
returns a true/false value depending on the presence of a <mark> record in the
timestamped interval ... and I think I can do this in a way that involves no
extra archive scanning for the common use case. Then PMAPI clients processing
archives that want to do rate conversion on counters and care could call
pmCheckContinuity() after each pmFetch() and take appropriate action.
This is obviously tricky, I just wish we had a better forum than BZ (like a
workshop) to resolve issues like this.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=dGe6jBiXpj&a=cc_unsubscribe
|