[pcp] RFC: ruminations re. avahi/etc discovery API

[Frank Ch. Eigler]

Hi -

Just a couple of thoughts re. the forthcoming pcp daemon-discovery API
brolley's working on.

The most straightforward thing to do would be to have a new libpcp
function that is a dual of the internal __pmServerAvahiAdvertisePresence(),
taking a serviceSpec ("pmcd") and return a vector of {IPaddress,port#} from
one-shot avahi search.  Basically, the same as

  % avahi-browse -r -t _pmcd._tcp | egrep '_pmcd|address|port'

... but actually, instead of a structure coming back, let's use a pcp
host-spec string.


A possible initial client for this API would be a "pmfind":

  % pmfind pmcd --discover
  pcp://192.168.1.13:44321/
  pcp://192.168.1.14:44321/
  pcp://192.168.1.18:44321/

and pmchart's pcp-data-browser dialog box would be a close second.


A decision point is whether the API, or pmfind, or neither, should
confirm that the discovered servers actually are available, by making
a test PMNewContext connection to them.  How about doing it in pmfind
rather than the libpcp api, as in:

  % pmfind pmcd --check=pmcd.hostname --discover
  pcp://192.168.1.13:44321/     foo.bar.com
  pcp://192.168.1.14:44321/     joe.bar.com
  (eliminating .18 due to no connection, or no such metric)


Another decision point is whether the API should be strictly one-shot
or whether it should provide asynchronous notifications (like the
underlying avahi API can; like avahi-browse without -t).  I suggest
for now making it one-shot.  A client would have to compute
differences between subsequent calls.


Another decision point is whether the API should generalize to other
types of discovery.  Eventually, we'll also want the ability to
actively probe a network, as in

  % pmfind pmcd --probe=192.168.3.0/24:44321
  pcp://192.168.3.0:44321/
  pcp://192.168.3.8:44321/
  pcp://192.168.3.221:44321/

but this kind of probing naturally requires new parameters for the
underyling discovery function.  It also could be a (future) separate
function, but I'd prefer to keep it as one, due to cartesian product
explosion with other options, such as ...


Another decision point is what else to possibly discover other than
PMCDs.  nathan's unified-context idea (where clients would connect to
a new proxy/archive server that contains historical+live data about
some other PMCD, and use the PMAPI wire protocol + log-archive-like
time/seek commands) relates here.  This is another parametrization for
discovery, engaging in some flights of fancy:

  % pmfind pcpu --discover --hostid='joe.bar.com*'
  pcpu://192.168.1.99:44325?hostid=joe.bar.com/0f2382304983
  pcpu://192.168.1.100:44325?hostid=joe.bar.com/0f2382304983
  (where .1.99 happen to run pmloggers that collect .1.14's pmcd data)

  % pmchart --hosts `pmfind pcpu --discover --hostid='joe.bar.com*' `
    ... to browse to the past and back to the future ...

Or to find pmwebd's perhaps:

   % pmfind pmwebd --discover
   http://192.168.1.3:44323/pmapi
   http://192.168.1.4:44323/pmapi


Anyway, enough of that fantasy.  If no one can think of other relevant
I/O generalities, how about adding a libpcp general-purpose discovery
function:

   int pmDiscoverServices(
       char ***urls, /* output string array
                        allocated as per pmGetChildren/offspring */
       const char *service,  /* "pmcd" or such */
       const char *discovery_domain);
                             /* "AVAHI" or (later) "PROBE:IPV4:a.b.c.d/e:f",
                                service-dependent syntax. */


The --check functionality would go into pmfind as a post-processing stage.

What thinkst thou?


- FChE