Hi, Mark -
> I'm still worried about the error checking. Can't see any sane way
> to use ambiguous sentinels, especially returning 0 to flag an error
> for int valued instantaneous or discrete metrics. Either we keep
> internal error state and provide a function to query it, or mandate
> the currently optional err vector be passed in.
A few existent pmfg applications do show sanity with the 0 sentinels.
And still, no matter what, we cannot force an application to query the
error-state function, nor to look at a mandated err vector, nor to
even look at a pmapi status code returned from a function. C is like
that.
> For py binding, the err code would naturally be just be another attribute
> of the object, e.g.
>
> disks = fg.extend_indom("disk.dev.read")
> for inst, name, rdops, err in disks():
> if err:
> ...
For the python binding, per-metric errors are already always collected
and signalled with an exception when the value object is called (i.e.,
"rdops()"). This is documented in the PCP_PG.
> [Re. events,] perhaps fully generic vector-of-trees event data could
> be converted to/from an object notation, such as json. [...]
That would lose the pmfg flavour of unit/scale/rate conversion on a
per-metric basis. Maybe someone could extend pmExtractValue to
support a PM_TYPE_EVENT -> PM_TYPE_STRING conversion?
> [...]
> pmGetFetchGroupContext is missing from the C SYNOPSIS in the man page.
> int pmGetFetchGroupContext(pmFG pmfg);
It's there, #5 of 6.
> The man page says :
> This function returns the private PMAPI context used by the
> given fetchgroup. It may be used to adjust some
> configuration parameters of the context, such as via
> pmSetMode, but only before fetchgroup extension and fetching
> begins.
> How come the private context so restricted? Many tools will want to
> use pmSetMode after setting up the extensions and after fetching has
> started - e.g. replay/rewind an archive, change the update interval,
> etc.
The subsequent text tries to explain: "... may disrupt fetchgroup
functionality". We have no way of knowing what lower level PMAPI
calls could do. A pmSetMode would shift the time point, putting at
risk rate-conversion history for at least one time step. A pmStore
has undefined effects.
I'll tweak the wording to make this clearer.
- FChE
|