On 12/14/2015 03:08 PM, Nathan Scott wrote:
pmcc is not just a fetchgroup-alike API, it does a number of other very
useful things too, abstracting code out from high level python scripts.
[...]
Updating pmcc to use pmfg should be useful on several levels - as you say,
Mark; it should cause a reduction of code in pcp.pmcc, and we need to have
a coherent plan going forward - otherwise we might see a last-minute series
of patches a couple of days before release, where folk try to second guess
the appropriate future API to use (*cough*).
So, we need to see a resolution to this - either as a "pmfg+pmcc" API or a
"pmfg+new-high-level-API" (if pmcc/pmfg cannot be tweaked to work together
Well, I see it as pmfg+pmcc, i.e. pmfg is extending pmapi but in no
way invalidates any existing pmcc or pmapi functions - we can use them
together or separately with no issues. Perhaps we should just be calling this
the fetchgroup extensions to pmapi. pmcc is orthogonal - we can have
future pmcc functions that call fetchgroup functions (e.g. instance filtering,
reconnect context, etc), and equally, code that uses fetchgroup
can naturally call legacy pmapi and/or pmcc.
& in that case, we need to see that new API, and understand why its needed
over pmcc) before any core libpcp fetchgroup addition is added - this lack
of cohesion is already causing confusion. [..]
I don't see where the confusion is - IMO it's not either/or. We're just
adding a bunch of functions to pmapi that make it easier to do a lot of
the common stuff like rate conversion, scaling, value extraction, etc
+1 for pmfg event metric support too, BTW; other fetchgroup implementations
like libpcp_qmc support 'em - any API being added into libpcp itself should
certainly be complete.
yep agree
Cheers
|