----- Original Message -----
> On 03/10/2015 01:06 PM, Lukas Berk wrote:
> > Hi All,
> >
> > I was asked to take a look at minimizing the base PCP installation
> > (RHBZ1182184[1]) and was experimenting with a few aspects of it. I'd
> > like to get some feedback before I start more indepth hacking on it.
> [ ... ]
> > Removing direct dependency in libpcp on Avahi:
> >
> > I took this to mean, add a ./configure --without-avahi option (invokable
> > via ./Makepkgs) which configures functionality via buildefs.h
> > accordingly in libpcp. Nathan, is this what you had in mind?
> There is already a ./configure option that covers this, although it is
> perhaps misnamed as --with[out]-discovery. The current implementation
> checks for he presence of the needed avahi headers and libraries. There
> are currently two methods of discovery; avahi and active scanning, the
> latter of which can't be disabled (and doesn't need that capability). I
> don't know if the name of this option can be changed at this point
> (Nathan?), but perhaps a the aptly named synonym that you propose could
> be added.
In the past we have simply renamed configure options as we see fit, so
personally I have no problem with renaming it to match how the code is
now.
> I understood this to be a similar item to the NSPR/NSS one. i.e. to
> implement dynamic loading of the avahi-client library on demand when
> needed using dlopen(3).
Yep. Have a look at src/libpcp/src/{discovery,avahi,probe}.[ch] Lukas -
Dave has built a "plugin" setup there, effectively, allowing different
service discovery and advertising mechanisms to live side-by-side - but
at the moment everything is simply linked in together in libpcp.
The general idea here would be to make this into a more formal API and
allow the plugins to become separate .so files to libpcp.so (so, e.g.
a libpcp_avahi.so with the external dependency) - there are many other
potential discovery/advertising methods that could be added here.
A configuration file (or more likely, directory-of-config-files below
/etc/pcp somewhere) would then allow the sysadmin to determine which
advertising and discovery methods to be supported at runtime (files in
there might be installed along with the plugin packages, perhaps).
We ideally want a more general pcp-wide configuration mechanism so that
things like NSS, SASL and other future things can be switched on / off
across all of PCP (these things often affect both monitor and collector
sides of PCP). So something like sysctl-for-PCP, I guess? On collector
side its likely to be an /etc-only configuration, whereas on the monitor
side we'd likely want to augment that with per-user ($HOME/.pcp/) state.
cheers.
--
Nathan
|