Hi guys,
----- Original Message -----
> [...]
> I wonder if this has got confused with an issue that was raised, namely
> the pmcpp appears not be providing much value, especially for clients
> using a local PMAPI context?
I think that's likely behind it - thinking about many bugs at once. It's
not clear to me either how best to proceed on that front either FWIW -
maybe the rpm install hook is the right place, but ISTR we had it there
once and it was removed (for some reason that escapes me now).
> > ...
> > Splitting pmdas out into separate packages:
>
> My concern here is the number of packages ... there are 78 PMDAs in the
> current source tree.
It would only affect the subset of these that have external dependencies,
which is not the majority of PMDAs. I definitely think we need to do this
one, even outside of the need from the containers POV - its been asked for
many times over the years by sysadmins, wanting us to do dependencies for
the PMDAs correctly (many of the perl PMDAs do not have correct deps, and
we go to great lengths to hide them from auto-rpm-deps for example, which
is not right).
> And as you foreshadow this sort of major package restructuring is going
> to be tough for those upgrading an existing PCP installation.
I'm not sure its as bad as all that - the compat package approach should
keep all existing installs working AIUI. Its a requirement to not break
anything on upgrades, of course.
> > ...
> > Splitting python client tools:
> > ...
>
> I don't favour the "pcp <tool>" approach over "<tool>". I don't see
> what that buys us, and seems to be orthogonal to packaging.
Its related because of the python dependency - we don't want to force the
need for a full python install for the many monitoring tools that do not
need it, if people/containers don't want or need that extra weight.
FWIW, the pcp <tool> approach gives two things - the ability for the tool
to maintain the "correct" interface in terms of command line options, for
tools which are drop-in replacements for system tools. The other is that
it can provide a meaningful diagnostic if the separate pcp-tools package
isn't installed. But, as Lukas said, both binary varieties can coexist.
Lukas, I'd suggest a name that is less developer-centric though, and more
user-focussed - maybe "pcp-system-tools" or "pcp-monitors" (anything with
python/perl/... in the name is also potentially a little ambiguous to the
user - i.e. "tools with python deps" or "tools for monitoring python"?).
All that said, the PMDAs does seem as good a place as any to start pulling
at this ball of yarn. Chatting to Mark yesterday, there was also mention
of pcp-pmcd, pcp-pmlogger, and pcp-pmie packages... something else to be
thinking about.
Oh, there was one other potential savings area missed from the list, which
is the link-daemon-PMDAs-with-their-DSO equivalent, e.g.
$ ls -l /var/lib/pcp/pmdas/linux/*linux*
-rwxr-xr-x. 1 root root 127256 Mar 12 09:02 /var/lib/pcp/pmdas/linux/pmdalinux*
-rwxr-xr-x. 1 root root 157304 Mar 12 09:02
/var/lib/pcp/pmdas/linux/pmda_linux.so*
Repeat that space saving for every PMDA we ship in both modes, and there's
a bit of low hanging fruit there too I suspect.
cheers.
--
Nathan
|