While I welcome the goal of making the default PCP install smaller and
more attractive to "out of the box, on by default" sorts of policies, I
think you should be warned that there is a long history of changes to
PCP packaging, and all of the variants have come with some warts for
some classes of users.
The scope of what PCP is covering is so wide that we are forced into
compromises at many levels.
Having said that, some comments below ...
On 11/03/15 04:06, Lukas Berk wrote:
...
Providing a default pmns, and not requiring a Rebuild invocation when
the pmcd service initially starts:
I am not sure about this one.
/var/lib/pcp/pmns/root is not in the packages, Rebuild and .NeedRebuild
are the mechanisms that ensure this is created the first time and
updated after a package upgrade.
I briefly experimented with this, by removing the initial .NeedRebuild
related commands in the GNUMakefiles and spec files, and running various
groups of the testsuite (sanity, verify, pmns, pmcd, pmda.linux,
pmda.pmcd, pmda.proc) with a fresh installation. There were no glaring
failures, related to not having a rebuilt pmns, afaict.
If it really was afresh install, how was /var/lib/pcp/pmns/root created?
... In an effort to
better understand this area, what was the historical reason for
rebuilding the pmns upon the first pmcd start? In the case the
buildroot/platform was different that the target installation? ...
The pre-installed PMDAs (which historically were the O/S kernel PMDA, so
linux or irix or freebsd or solaris or hpux or aix or ..., the PMCD
PMDA, but has expanded over time to include a few more PMDAs) never run
a ./Install script so there is no place to update the root PMNS as part
of a PMDA install.
Rebuild and .NeedRebuild create a new root PMNS by
1. if one already exists, remove all the names for the preinstalled PMDAs
2. if one already exists, remove any old names that are known to have
been deprecated
3. if one already exists, what remains is a PMNS for any of the optional
PMDAs that have been installed locally
4. merge in the root_foo PMNS for all of the preinstalled PMDAs
This is the only way to preserve the PMNS during an upgrade where
optional PMDAs are not reinstalled and the preinstalled PMDAs may come
with changes in their PMNS.
... If this
is a known issue on some select environments, perhaps we could still
keep/make use of the .NeedRebuild file for those platforms?
I don't know of any issue in this area, and don't see what this has to
do with reducing the PCP installation size.
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?
...
Splitting pmdas out into separate packages:
My concern here is the number of packages ... there are 78 PMDAs in the
current source tree.
And as you foreshadow this sort of major package restructuring is going
to be tough for those upgrading an existing PCP installation.
...
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.
|