Hi -
> [...]
> commit 42145e672b91bfb8a4cef29259640d9aa7493b4a
> Author: Nathan Scott <nathans@xxxxxxxxxx>
> Date: Fri Apr 11 15:48:38 2014 +1000
>
> [...]
> Add in support for pcp(1) to be used to invoke system tools
> as scripts (like the existing pcp-free, pcp-uptime scripts)
> with automatic argument passing/parsing. [...]
Just took a look at the new pcp-free.py script; nice and short.
Some aspects though concern me:
- a python-binding issue where clients must manually manage
pmResult memory, as in:
136 result = self.context.pmFetch(pmids)
137 values = self.extract(descs, result)
138 self.context.pmFreeResult(result)
Can we hide this within the bindings (implicitly extracting
values, and freeing the pmapi level results)?
- a coding-style issue, where this client makes assumptions about the
scaling values of metrics, specifically report(), which assumes all
values[] are in Kbytes. This happens to be true today, but there's
no guarantee that metric units/scales will never change. Such apps
should instead use pmConvScale to assert/adapt.
Perhaps both bullets are of the same kind: the python pmapi bindings
should automate metric value fetching / scaling / decoding fuller
(and more declaratively if possible).
- FChE
|