pcp
[Top] [All Lists]

Re: [pcp] [PATCH] Improve pmatop value fitting

To: Stan Cox <scox@xxxxxxxxxx>
Subject: Re: [pcp] [PATCH] Improve pmatop value fitting
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 18 Jun 2014 01:55:41 -0400 (EDT)
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53A094EF.3070306@xxxxxxxxxx>
References: <539623F5.1050902@xxxxxxxxxx> <1098064384.23885191.1402449908671.JavaMail.zimbra@xxxxxxxxxx> <53A094EF.3070306@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: D7XSK/QucHZxRfCiNLgphtkeWt6PmA==
Thread-topic: Improve pmatop value fitting
Hi Stan,

----- Original Message -----
> Not directly related to value fitting; but this change adds pmOptions
> option handling to pmatop and pmcollectl.
> 
> git://sourceware.org/git/pcpfans.git
> scox/dev 88e5276
> Stan Cox (1): Use python option processing class.

Nice, I enjoyed the pylint cleanup in there too.  :)

Attached patch tackles a couple of minor things.  Less minor though
is the way these tools now seem to be creating an initial context
(via the argument parsing helper), then another immediately after
depending on whether a folio was presented or not?

This seems like it'll be a problem in the folio mode, which will not
be able to run on a machine without a local pmcd anymore (to satisfy
the initial context creation, which we promptly discard).  To tackle
this, I think it'd need to do the folio parsing in option_callback()
and add the archive (manually) into the pmOptions.  Not pretty. :(

[ pmval has to do something horrifyingly similar, see its call out
to __pmAddOptArchive(). ]

To throw you another curve ball :) - folios can potentially contain
multiple archives, possibly even from multiple hosts, which this
code kinda skips right over.  See the example inside mkaf(1) - which
amusingly even predates the Y2K bugfixes in log naming - heh!  Now
there's a blast from the past!

Anyway, the pmOptions stuff can handle that, allowing for multiple
archives already.  I wonder if support for parsing folios should be
added into libpcp, however?  This will certainly simplify life here
- the downside will be having to parse the folio in C code instead
of python.  The alternative would be shifting it over to pcp.pmcc
(or adding pmOption support into pcp.pmsubsys until we get to move
these tools over to pcp.pmcc) ... but, probably libpcp will be the
simplest overall?  (libpcp_gui being yet another possibility, since
it knows all about the folio format already, which libpcp doesn't -
but libpcp_gui doesn't know about pmOptions at all - gah!).

I *think* doing it in libpcp will be the simplest approach; using
the code implementing PMOPT_HOSTSFILE as a reference.  So perhaps a
PMOPT_FOLIO might be the way to go (with a --folio option, and some
libpcp/src/getopt.c code similar to __pmAddOptHostFile).

Thoughts?

Once thats in place, these scripts become simpler - just need that
one pmapi.pmContext.fromOptions call, dropping the ~20 lines or so
of python code that follows it in each script.

cheers.

--
Nathan

Attachment: scox-options.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>