nathans wrote:
>> 1- This requires the client to divine pmcd server connection data for
>> the real-time component from the archives (or vice versa). Or else
>> force the a user to specify both?
>
> It starts from a host spec (just like pmlogger does), as described
> in the earlier unified context discussions.
That's not the complete story. There are one or more archives, zero
or more pmloggers, and a pmcd server. The client would need
information about all those, not just "a host spec". (The attraction
of using a pmlogger-like thing as an intermediary is that -it- would
already have info about all those things.)
>> requests from live pmcd would be available; but data that the PMAPI
>> client *recently requested* wouldn't be.
>
> If it needs to persist, pmlogger needs to write it. [...]
Exactly, but we don't draw the same conclusions from that.
> This scheme where clients have to force all data to be written to
> disk, via a system daemon no less [...]
No one said it'd have to be a *system* daemon. For example, pmlogger
is fully usable as transient & personal program.
> [...] Many tools definitely do not want that - we simply cannot
> mandate that behaviour.
Tools that don't need "grand unification" don't need to use this stuff
at all. Tools that just want to listen passively to archives and
actively to pmcds of their choice can already do so today: just open
two pcp contexts (an archive and a host).
(Tools that want to monitor -growing- archives will need to wait for
archive-tail-f type functionality in libpcp and make some minor
changes in their own code, as we outlined back in January. [1])
[1] http://oss.sgi.com/pipermail/pcp/2014-January/004260.html
By the way, in your mental model, do you plan to address the needs of
tools that would like simply remote access to archive data (not pmcd,
and without locally reachable archive -files-)? The pmlogger-proxy
idea can do that. (Or is that niche to be reserved for pmwebd?)
> [...] there's a raft of issues.
Certainly.
- FChE
|