Hi,
On 2015-12-02 04:15, Nathan Scott wrote:
>
> I've pushed through the first big batch of your pmrep changes now.
awesome, thanks!
> think we still need: a version# in the config file (somehow? see my
> IRC q from overnight - first line? [options]?),
That would be easy and something that is used elsewhere as well, an
example from sssd.conf(5):
config_file_version (integer)
Indicates what is the syntax of the config file. SSSD 0.6.0 and
later use version 2.
> the pmrep.conf.5 man page (sounds like you have that under control)
Yup, "90% done" ;)
>, and the non-options handling should switch to the pmOption API
The patch I sent was to unify naming:
http://oss.sgi.com/pipermail/pcp/2015-November/008795.html
But there was an issue which doesn't allow using it for this case:
http://oss.sgi.com/pipermail/pcp/2015-December/008835.html
> Are there any other pmrep items before the initial release?
I'm thinking of the following:
- sync my latest local copy with upstream, few minor improvements
(coming after this email)
- fix get_cmd_line_metrics() (see above)
- possibly merge the unit/scale and raw config fields (they can't be
used together anyway so makes it a bit simpler and is also matches
fetchgroup interface)
And if you think things like changing decimals -> precision would be
worth in the config file (as you did in the man page), we could still do it.
What was the current schedule for 3.10.9 btw?
> It'd be good to have some more test cases - could you suggest more to
> add to 1068 (zabbix-parts) and 1069 (general pmrep)? I must have done
> something incorrectly in the derived metrics use (see comments toward
> the end of 1069) - can you take a look & spot my error there? Taa.
For the Zabbix part my next email illustrates what the test didn't
catch/cover. Wrt 1069 there's a todo list item to handle derived metrics
with archives, I tested it once some time ago and noticed that it didn't
work but didn't investigate in detail, merely added the note.
> In terms of the zbxsend module issues, after poking around the python
> code you pointed me to (thanks) I think it does make sense to pull it
> into pmrep for now - fixing the py3 issues, packaging issues, etc. It
> is very small, very simple, and will make life significantly simpler
> for both users and us as developers. So I went ahead and did that, as
> well as a handful of other small changes - please review 'em & update
> as you see fit, thanks!
Hmm, ok, I see you embedded it, I was thinking to have it as a separate
"pcpzbxsend" or such module to keep it separated to make it clear how we
deviate from upstream. Anyway, I'll send a separate email with a patch
to fix the remaining py3 issues still in it.
> For future releases, if we can abstract a pmrep API for pcp2xxx tools
> I think a pcp2zabbix(1) would make good sense (that bit of zbxsend code
> could then live in there, outside of the shared pmrep code). In that
> model, I imagine both pmrep and pcp2zabbix as small front-end scripts
> (100 lines or so, tops)... but thats something for later, lets get the
> core functionality finished off and well-tested now.
Yes, something to provide your custom config options (if any), then use
the common code to get the wanted results and have few callbacks to
handle them as you like. But let's think about this more later.
Thanks,
--
Marko Myllynen
|