Hi all,
We're starting to see interest in folks using PCP services
from within containers, and some of the needs they have are
quite interesting.
Numero uno, so far, is to drastically minimise the installed
footprint of the core functionality. This definitely means
pmcd and the default agents but to a lesser extent also would
benefit from reductions in other areas too. The reason for
wanting this smaller install footprint, AIUI, are to do with
storage resources required across many container instances.
Thus, any changes we make along these lines will likely help
with virtualization in general.
A few things that spring to mind to help with such an effort
would be:
1. Extracting a small "core" functionality package from "pcp"
(rpm/deb) package that provides pmcd, core PMDAs and possibly
pmlogger (although I suspect things will start to unravel if
we go that far - pminfo, pmlogconf, ... alot get dragged in).
I think this part would largely be a packaging kinda problem,
rearranging spec files, rpms/debs - providing a dependence on
"pcp-pmcd" from base "pcp" package so that upgrades work, and
installing "pcp" still gets all the needed packaging.
2. Many PMDAs (including "core" PMDAs) have both daemon & DSO
variants which duplicate a bit of code (hence increasing the
installed package size ondisk). I wonder if we could move to
a model where the daemon PMDAs in such cases use the run-time
DSO, instead of linking with the .o at build time? (this'll
need a new libpcp_pmda helper function to wrap the dlopen(3)
call).
3. PMDAs that link with external libraries should always be
packaged via the pcp-pmda-xxx packaging model, so that those
external libraries and their dependencies are not dragged in
by default too. Jeremy hit this with pmdasystemd, but there
are others too (pmdapache, pmdarpm). Should we extend this
out to the perl/python PMDAs? (I think we probably should).
If so, singularly, or as python PMDA sets and perl PMDA sets
perhaps? And then there's the python client tools being in
"pcp"... maybe these become "too hard" to split out (consider
the impact on the users too with fanout of packaging in this
way - not so friendly).
Does anyone have thoughts on the above? It'd be good to begin
a tracking effort for identification of any other low-hanging-
fruit size wise, and to track (on-going) our package sizes.
Anyone know of other space saving possibilities in either this
new proposed core package area, or the wider pcp packages? Oh
this extends to in-core memory footprint too, so any ideas in
that direction would be good to hear about too.
Thanks!
--
Nathan
|