Hi -
> [...] 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? [...]
I don't know; the code might happen to lump fetches together.
> > 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
No, the problem of stateful pmwebapi contexts does not currently
exist. Implementing indom-profile manipulations would bring them into
existence, and this proposal would make them worse.
> > 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.
I'm aware of that. But up to this point we could afford to be lazy
with that stuff, because pmcd enforced a blanket no-untrusted-store
constraint (with "remote" being an fuzzy version of "untrusted"). If
that is to be loosened, so all pcp clients can do stores, then
security concerns dictate that every pmda that handles stores needs to
be audited & ACL machinery applied.
> [...] Could you outline the sorts of changes pmwebapi & pmwebd
> would need in order to support pmInDom profiles and pmStore? [...]
The profile-related and store-related facilities would need a new
function each in pmwebapi.cxx, along the lines of
pmwebapi_respond_metric_fetch(). The store one could be modeled
in pmwebapi as a sibling of _fetch:
/pmapi/XXXXX/_store?names=NAME1,NAME2&value=VALUE
/pmapi/XXXXX/_store?pmids=NAME1,NAME2&value=VALUE
By the way, how much processing time or space does this approach
(pmStore then pmFetch) save, over doing it with current PMAPI, namely
a temporary pmNewContext (with different "&container=XXXX"), pmFetch,
pmDestroyContext? The number of messages or latencies are not
obviously-to-me inherently different, esp. considering the libpcp
reuse of active connections. If there exist overheads that are
optimizable in the pmNewContext case, it would benefit all the apps.
- FChE
|