Hi Stan,
----- Original Message -----
> This is a first cut, not committed, to add an pmda for rpm. It uses the
> python pmda bindings and the rpm python module. It keeps a list of
> active packages in the pmda and each metric request is serviced by
> querying using the rpm python module.
>
A few things spring to mind on review ...
- I don't think the instance handling is right - there appears to be no
protection between the helper thread and the main pmda for updates to the
instance domain? Both of which are reading/writing self._indoms[] from
the python class MetricDispatch.
- At the end of instance() the indom needs to be refreshed. The next
thing the libpcp_pmda code will do after the python instance() method
is called, is to respond to the client with the list of instances ...
so, just kicking the thread to go and gather the data (which'll finish
at some arbitrary-but-hopefully-soon-but-maybe-not-soon-enough point
later) doesn't quite satisfy the requirements of the instance PDU code
in libpcp_pmda.
- The above 2 points make me think the thread should instead take some
kind of inotify/dnotify/whatever-its-called-nowadays approach, where it
gets async notification of changes to /var/lib/rpm/Packages and updates
the instance domain in the background, independent to instance().
- How big does this instance domain get btw? Is it "rpm -qa | wc"
sized? (on my system atm - sample size of 1 :) - 1818 1818 62086)
Not terrible I guess, but is that normal? Wondering what the memory
requirements of this PMDA might be in steady state. Something to keep
in mind anyway.
- This information is potentially highly sensitive - it'd be useful to
know when attempting to penetrate a system exactly what versions of all
packages are installed, as this will tell us which vulnerabilities are
not patched... :) At the very least, this needs to be protected by the
credentials attributes. But again, we should take a long hard look at
ourselves and feel comfortable that the risks of exposing this data do
not outweigh the benefits - it'll make pmcd a higher value target.
- The above point means we need to tackle attributes in python (there
is a stub in src/python/pmda.c which will need more love, especially
around line 595).
- When the time comes for packaging it, lets consider tackling this via
the route the Infiniband PMDA takes -> new sub-package (pcp-pmda-rpm?).
This helps keep the package dependencies on the core pcp package to as
small a set as possible, and the optional-extra rpms carry those extra
python deps (rpm-python, & whatever the *notify API comes from).
cheers.
--
Nathan
|