On 12/16/2015 07:56 AM, Frank Ch. Eigler wrote:
Hi -
[...]
Please see the rebased fche/fetchgroup branch for a v3.
The remaining work, AIUI:
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.
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:
...
- blurbage in books ... pcp-programmers-guide; planning to
replace/update discussion of pmclient.c
I'll rv that over the w/e .. out of time today
- think about how to expose events to pmfg; irc thinking-out-loud
transcript follows. I'd appreciate a thought-review before I go
and try to hack it up.
<myllynen> fche, btw, it's obvious that event support in pmfg is not trivial
but what's your current gut feeling about it, is it even worth the shot or will it be
too messy?
<fche> I think it's only practical to address restricted cases of it
<fche> ie not the whole vector-of-trees
perhaps fully generic vector-of-trees event data could be converted to/from an
object
notation, such as json. THat way the APIs would just pass around the resulting
strings
and it'd be up to the app to decode the json event data. Might be too expensive
for
high frequency event data though (?)
commit a09ce18bab614da812a22547991726cf4f72742f
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Tue Dec 15 15:16:26 2015 -0500
pcp fetchgroup v3: with a more private context
As per review comments:
- a fetchgroup now owns a private pmapi context it creates via
pmNewContext, so pmDupContext is no longer relevant
- ... which it is willing to expose, with appropriate documentation
cautions
pmGetFetchGroupContext is missing from the C SYNOPSIS in the man page.
int pmGetFetchGroupContext(pmFG pmfg);
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.
- which moots pmFetchGroupSetMode, so it's gone
- tests extended to cover interleaving,
- rate conversion failure due to missing history is PM_ERR_AGAIN'd
ok, seems a better err code, and the typically awful py error reporting can
be managed with appropriate exception handling by the calling app.
- a little bit more initialization is promised by a few few functions
pmstat, pmclient, pmmgr, python-bindings, test cases updated. pmmgr
more fully converted to pmfg (the container enumeration was previously
overlooked).
will rv over the week-end too.
Cheers
|