Hi -
> [...] I like the general idea of finding archives (which the
> unified context mode will need), but not via pmDiscoverServices -
> new API(s) would make more sense IMO.
Yes, perhaps.
> > [...] ",basedir=xxx"
>
> I have some security reservations about allowing remote users to poke at
> a far away system via pmwebd to determine whether arbitrary files exist
> or not (based on return codes or response time) - it would have to be
> limited to a set of well-known locations (eg /var/log/{pmlogger,pmmgr}).
>
This concern is reasonable but misplaced. The proposed
archive-discovery facility is a pure libpcp client-side one, just like
the pmcd-discovery one. Neither would be intended or safe for full
direct exposure to remote users. (In the pmwebd case, I imagined
pmwebd using it internally, to search the sysadmin-configured
archive-ACL directory (pmwebd -A dir).)
See also http://oss.sgi.com/bugzilla/show_bug.cgi?id=941
and http://oss.sgi.com/bugzilla/show_bug.cgi?id=1052.
> And its not clear raw archive paths should be exposed at all via the
> web API, a unified context with multiple archive support seems
> cleaner.
There'll be always a need to pinpoint individual archive files, not
only unified forms (once that feature arrives) -- or are you thinking
about removing pmNewContext (PM_CONTEXT_ARCHIVE, "filename.meta")?
> > - filter for archive-label matching given hostname
> > ",loghost=BAR.BAZ"
> > - filter for archive-label covering all given TIME(s)
> > ",logtime=TIME,logtime=TIME"
> > - filter for archive metadata including metric
> > ",metric=PMNS"
>
> This could be an arbitrarily complex filtering language [...]
Yes, it's tempting to overdesign. I think expressing these in the
discovery api would only add value if it could evaluate such
predicates more efficiently than the client could. In the case of a
simple archive enumeration, and those predicates, that's probably not
the case, so these were just flights of fancy. Forget I ever wrote
them. I already have. What were we talking about again?
> > - limit directory recursion
> > ",maxdepth=NN"
> > - limit time
> > ",timeout=NN"
> With a fixed set of locations, these last examples become unnecessary [...]
These on the other hand do impact the search mechanics, and would make
some sense as discovery parameters. It's not hard to imagine having a
centralized archive of thousands of hosts, maybe on slower
fileservers, where we don't want the search to be too long.
> Hmm, above suggests we should've thought of an "options" parameter
> to pmDiscoverServices(3). [...]
One benefit of keeping options textual and similar is for their direct
transposition to a user interface like a config file or a pmfind
command line argument. Sure, one could create some enum tuple widget
like ... __pmOptions (?), but then it needs to just hop between ascii
or multiple flags elsewhere anyway, with much more complexity. (Or
did you simply imagine adding another 'char* options' parameter to
the discover api?)
- FChE
|