----- Original Message -----
>
> nathans wrote:
>
> > Personally, I was unconvinced that the recent round of suggestions was a
> > step forward, so for me definitely not "replaced" ...
>
> > I do still have a strong preference for Plan A; everything stated
> > there matches my current thinking re the ideal long term approach we
> > should take ("Plan A" being:
> > http://oss.sgi.com/pipermail/pcp/2013-September/003963.html)
>
> That message spells out a number of capability/user-interface
> desiderata, without much of a proposal for implementation mechanics.
> Since that message, further conversation indicates Nathan believes
> that libpcp would be a good place for all the intelligence needed to
> overcome the many complex issues he lists.
>
> 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).
> proposed a specific two-staged implementation. Here, libpcp does not
> carry any significant complexity, only the single-growing-archive case
> ("stage 1", "-a ARCHIVE").
> For the more-complex cases ("stage 2"),
Issues with overloading existing context types are also of concern in
terms of shoe-horning different semantics onto the existing mechanics
of calls as fundamental as pmNewContext (which mandates one archive
only for ARCHIVE contexts, and mandates failure in the case of a down
host in the HOST context case - neither of which are semantics that
we want here). We can use flags (which I feel is attempting to shoe-
horn a big, important concept into places we shouldn't), or we can
use the more clear barrier that a separate context type would be.
In practice, I don't really know how it will turn out - it feels like
a BIG change, in terms of impact on the client tool code & on libpcp
code beneath that, hence my initial preference for a new context type.
This offers very clear back-compat behaviour for pmNewContext - "this
tool does not support this yet" kind of thing, which I'm convinced we
will need for all tools of complexity > pminfo/pmprobe - i.e. most of
'em.
> 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.
IMO, it is a major limitation for clients to require the presence of
a server when replaying (multiple) archives (transparently) & another
usability failing to mandate that everything now has to be logged to
an archive, somewhere, before clients can access the data.
> pcp clients would connect using a slightly extended pcp wire protocol,
> but the same "-h SERVER" user interface.
*nod*, any/all proposals need protocol changes. Nobody's fleshed any
of these out yet, but they're the same kinds of PDU changes whatever
way we choose to go. They are more critically important in the latter
approach, because everything requires PDUs to a daemon, whereas that's
not the default mode in the former model - but both will need 'em.
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.
> So we need to resolve which of these should be pursued. However, for
> brolley's purposes, initial focus on the single-growing-archive case
> seems to be common to both possible paths.
*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.
cheers.
--
Nathan
|