----- Original Message -----
> > [...] One relatively straight forward approach to improving things
> > would be to allow clients to (optionally) change the container
> > associated with a given context at any time after context creation.
>
> For highly asynchronous continuation-based systems like
> vector/javascript, this newly stateful pmwebapi context# would be a
> complication. It means that operations on a shared context would have
> to be precluded or carefully sequentialized, since the (new)
> change-context and (old) normal-fetch operations must now be
> atomically paired.
Yes, that is an interesting point. Does this "context sharing" actually
happen currently? Its something else for me to talk to the Vector guys
about too, thanks.
> At the moment, the same context# can be reused concurrently (ignoring
> indom profiles).
Well, lets not ignore them - what you're saying is this problem already
exists but so far it's been ignored (looks like an API has been thought
through, and documented on PMWEBAPI(3) though). Server-side filtering
is useful, in any of its many forms (InDom profiles being just one),
so let's ponder it some more and see if we can solve multiple problems
at once here.
FWIW there are actually other places where dynamic server-side state
happens already (any PMDA can choose to maintain per-client state, of
course, including 3rd party PMDAs) - so, this is a problem worth time
and effort to solve for pmwebapi access too if we can. That seems a
better option than ignoring it, and inventing new wheels, anyway.
> This change may require vector to use numerous
> pmwebapi contexts (for concurrency control),
*nod*, but at this stage Vector is already going to need numerous
contexts (for each container it wishes to fetch from).
> in which case we would not really save anything.
Either way, we neatly solve the problem for regular PMAPI clients like
pcp-atop of course - so we're definitely ahead in some places.
> > [...] I've looked into extending that idea so that it becomes a
> > pmStore(3)-able metric. [...]
>
> While pmStore exists, its current access control mechanism
> (/etc/pcp/pmcd.conf) is such a blunt instrument that IMHO we
> need to revisit that before relying on it further.
You are perhaps overlooking that PMDAs get to apply whatever access
control they choose above and beyond the gated entry pmcd provides.
So, arbitrary ACLs are already possible at a per-metric level (and
that is as fine-grained as we'd ever need) - no revisiting needed.
libpcp even provides PMDAs with some per-user, per-group & per-host
access control interfaces, if they wish to use those, or they can
choose to use whatever ACL method they wish.
> Have you considered extending PMAPI formally, maybe adding
> an attribute-string spec to pmFetch (which could include the
> container=XXXX stuff)?
Firstly, attributes are inherently sticky (they are connection
attributes, not PDU attributes - think about the other PDUs too,
it is not just fetch that is affected) - and the PMDAs treat them
that way, associating state with each individual client for the
life of the client connection. Anything other than that is ...
Secondly, it'd be an *enormous* code change - a number of new PDUs,
incompatible clients/servers to deal with - protocol rev'ing, alot
of new client code, alot of new server code, new client APIs, new
PMDA APIs - the works. And the only user would be the web API.
It also won't help us tackle the existing, more general problem of
server-side filtering for web clients (indom profiles and pmStore
support in pmwebapi) - which we should do, they are both useful
facilities.
Could you outline the sorts of changes pmwebapi & pmwebd would need in
order to support pmInDom profiles and pmStore? I suspect it would be
just fine to assert that web clients wishing to use server-side state
(it is opt-in) will need to manage their contexts accordingly. The
API you've added to PMWEBAPI(3) for profiles looks OK to me - but what
would a "_store" end-point need to look like I wonder? Thanks! (and
thanks for the feedback too)
cheers.
--
Nathan
|