Heya Marko,
----- Original Message -----
> [...]
> Here are the changes I've now done for pmrep:
>
> - fix the pmDebug case
> - pylint cleanups
> - Python 3 / Fedora 23 support
> - PCP 3.9.10 / RHEL 7 support
> - Python 2.6 / RHEL 6 support
> - support for the new metric spec syntax
> - adjust for recent recording changes
> - Zabbix support
Good stuff!
> I also investigated pmcc a bit more. There's certainly some appeal in it
> already but I'm not convinced to change pmrep quite yet; I think it
Okie doke, no problem.
> would be a good idea to wait for the pmFetchGroup API to land and it to
> propagate to the Python PMAPI, it might be an interesting alternative as
> well (pmFetchGroup API has seen some activity since my previous pmrep
As we discussed on IRC, that is at a much lower level than is relevant at
this stage of evolution of a generic reporting API - if/when another new
fetchgroup API comes along, it will be required to sit below these higher
level APIs to prove its worth. So currently I'm more concerned about the
high level API - pcp.pmcc is the start of one such API, but we don't have
to use that if it doesn't suit... we'll see.
The 'cc' in pmcc stands for "Convenience Classes" - when current pmcc does
not suffice (and it definitely will not - doesn't try to do this level of
reporting granularity) we should be thinking if/how we can extend it with
classes more convenient for generic reporting scripts.
> Also, before starting possible internal surgery which should not affect
> current user experience, I think it'd be beneficial to have some QA
> tests in place to make sure we don't break anything while using the scalpel.
Absolutely.
> Which brings us to the interesting question of merging pmrep. Now I have
> it only on my local repo which is of course a quite silly, writing the
> man page and QA would certainly be easier if part of pcp.git. Or did you
Do you have a public git repo somewhere? (github?) Would it make life any
easier if you had a git.pcp.io account for your pcp tree? (if so, please
send thru your public ssh key if so & I'll set that up)
> have some hard requirements in mind before merging?
There's no rush to merge, plenty of time in the current release window. The
best next step will be writing up test cases for all of the existing export
functionality that you have working, so that we don't go backward from there.
We will want man pages and so on too before merging, but that can come later
- automated testing of the currently-working-stuff would be most helpful at
this stage.
This doesn't have to be in pcp/qa format yet - I can help with that later.
Just a series of commands to run, and the expected output. Maybe focus on
the csv and basic stdout reporting before Zabbix, since they're simpler to
test - and try to get coverage of how pmrep handles all the different types/
units/semantics/... of metrics, the different types of formatting, scaling,
etc.
Use pmdasample metrics - that gives us a good variety of data, behaviours,
whacky instance domains, metric types, etc - and its cross platform (which
the kernel metrics tend not to be - so they're sometimes less suitable for
this kind of regression testing).
I'm away until middle of next week, but if you have some extensive testing
in place when I'm back, I'll work on a full review, building pcp/qa tests,
then we can modularise, document, and merge it.
cheers.
--
Nathan
|