----- Original Message -----
> > [...] 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.
>
Hmmmm. This sounded interesting at first, but now it sounds more and
more like its not happening in practice & a bit of a distraction. As
it appears noone is doing this, and both profile/store are both going
to be opt-in operations anyway (iow, if a utility doesn't use 'em, it
could still do this theortical context sharing) - doesn't seem overly
concerning now.
> security concerns dictate that every pmda that handles stores needs to
> be audited & ACL machinery applied.
If you like, sure, but I know most/all of the store metrics and none are
of particular concern to me off the top of my head. So, let us know how
your audit goes - any issues there are independent of this effort though
(iow, via pmcd & existing clients, not new to pmwebd).
The SECURITY section in pmwebd(1) reads like a horror story, BTW, so it
is "kettle, pot" territory saying store *might* introduce issues when we
are already significantly exposed there.
>
> > [...] 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:
*nod*
>
> /pmapi/XXXXX/_store?names=NAME1,NAME2&value=VALUE
> /pmapi/XXXXX/_store?pmids=NAME1,NAME2&value=VALUE
>
OK, I'll expand on that and push something through in the pmwebapi(3)
man page shortly - the above does not cater for indoms yet and there's
no situation where one value would suit multiple metrics - but easy to
tackle those.
> By the way, how much processing time or space does this approach
> (pmStore then pmFetch) save,
Think more about how many sockets and open file descriptors are needed as
the container count increases - that makes the current model impractical
for certain situations. e.g. for browsers that cannot open more than a
handful of connections to one source (the Vector guys who are doing this
containers work are already observing this).
That said, there are definitely situations where it is going to be cheaper
and easier to use store - but, this is a bit of a distraction to the topic
at hand. Thanks for the feedback, I'll follow up later with the pmwebapi
work (next release) adding _store for Vector (containers & soon pmdapipe).
cheers.
--
Nathan
|