Hi, Nathan -
> [...]
> > My recent message assumed approximately the same desiderata, and
>
> Hmmm - not really convinced of that. In terms of functionality, to
> me it feels that the latter is a subset of the former. And quite a
> significant subset in ways that I value (multi-archives, no daemons
> for archives, and the direct talk-to-pmcd live mode).
Actually, I mentioned explicitly the multi-archives support via the
new server. "no daemons for archives" was to be different only for
the multiple-archives case, and it's not a "functionality" subset but
perhaps a logistical simplification. "direct talk-to-pmcd" was to be
done via the same new server process, possibly using an
dynamically-reconfigured archive there as an intermediary. And this
enables functionality that your scheme doesn't: automatically
archiving data that any live-mode client asks for, so that transitions
between the long-past, the just-past, and live-mode are seamless.
> [...]
> > all the intelligence would be loaded into a server process, to whom
>
> The complexity has to live *somewhere* and there's no real difference
> if its in libpcp or in some daemon, from a maintenance POV. Housing
> it directly in libpcp does offer the no-daemon-needed flexibility to
> clients (and pmproxy is a client, as is pmwebd) - so it seems an easy
> choice to me.
As we discussed in IRC, one downside of that approach is the necessity
to encode all the configurability of that intelligence within a new C
API, or else to hard-code it all within libpcp. (It would be
unappealing to feed a complicated configuration file to libpcp, no?)
> IMO, it is a major limitation for clients to require the presence of
> a server when replaying (multiple) archives (transparently)
Why? Servers don't need to be expensive to start up. They can share
resource between multiple clients. By having the administrator of the
site-specific logging infrastructure configure them once, the clients
don't have to be repeatedly configured.
> another usability failing to mandate that everything now has to be
> logged to an archive, somewhere, before clients can access the data.
The use of an archive as an intermediary would be hidden from clients,
so would be barely visible, let alone a failing.
> Last, but not least wrt usability (for some folks anyway - it doesn't
> bother me after all this time) - we can move away from -h to -u with
> this new context type, in a controlled, backward-compatible way, over
> time.
With my proposed scheme, current (-h live-mode) clients would work
identically: no user interface, nor API use changes, just a different
-h parameter (to talk to the live-archive server rather than pmcd).
Current -a single-archive clients, likewise. It's all
backward-compatible. It's only the new permutations, those formerly
forbidden by PMAPI (live-mode on -a, time-seeking on -h), which the
stage-1 & stage-2 extensions would allow.
> *nod*, definitely worth further work being done there (looks like
> kenj has invested significant effort on that path already, a few
> years ago, from a recent scan in some of the affected code).
> Securing the pmlc / pmlogger connection is something else that could
> be tackled early on - it is needed no matter what. Similarly, user
> auth for pmproxy needs to be tackled. Doing these things first will
> also give us time to get a deeper understanding of the issues,
> existing protocols, and so on.
Those are good ideas.
- FChE
|