----- Original Message -----
> 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(),
Or __pmServerAdvertisePresence even. We should keep in mind these similar
sorts of projects - http://www.openslp.org/ (which is apparently snia.org
blessed) - and other cloudy types. As mentioned on IRC sometime back, an
indirect (dlopen'd) kinda model more like SASL still seems a nice option,
so that we don't have to link pmcd/libpcp directly with all mechanisms.
Which, I think you *have* indeed kept in mind, with final parameter here...
> 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. */
So, looks good to me. :)
On a related note - chatting to the thermostat folks the other day, they
were interested in a non-root-requiring mechanism for detecting freshly
started java processes. For this case the sampling-style interface of the
PMAPI is not especially well-suited, so maybe PMDAs could begin to announce
"services" like that that they've found (assuming a pmdajvm, and an inotify
style of interface on the newly created hsperfdata directories)?
Virtual machines (guests), libvirt - might be another case where we could
help new analysis tools to find newly created/destroyed guests. But, maybe
not out place.
Or is this (ab)usage going too far? (will the above discovery API handle
the quirks of these other advertisements? not sure)
[ re thermostat - we should get announcement calls into pmwebd as well. ]
cheers.
--
Nathan
|