pcp
[Top] [All Lists]

[RFC] dynamic container switching

To: PCP <pcp@xxxxxxxxxxx>
Subject: [RFC] dynamic container switching
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 15 Oct 2015 01:22:00 -0400 (EDT)
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1313883527.54143616.1444783810135.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: s/4WR08BfZATxw/hSjPfKWgUfY7wVw==
Thread-topic: dynamic container switching
Hi all,

I've been hacking on containers support in client tools for awhile
now, more recently with Henry working on the Vector side of things,
and we have begun to find that although the 1-container-per-context
approach we've used to date is working well for all the simpler PCP
tools, it can become problematic when larger numbers of containers
(contexts) are needed.

Partially this is a problem with our way of accessing metrics that
are related to containers (N-dimensional data on top of often 2/3-
dimensional data sets already), and partially its because contexts
become unwieldy when many of them must be managed.

Since both the atop-based code and Vector are seeing similar kinds
of issues, I've been looking for refinements to the access method
for container-specific metrics (IOW network.interface.*, filesys.*,
proc.*, cgroup.*, etc) that these tools can be extended to use, and
at the same time keeping backward compatibility of course.

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.

Recently, there was discussion about exposing the server-side name
of a container via a pmcd.client.container metric (handy for issue
diagnosis even now).  I've looked into extending that idea so that
it becomes a pmStore(3)-able metric.  Initial implementation will
follow, but basically a client tool is able to switch at runtime
different between containers and the host, for each pmFetch (and/or
other PMAPI operations).

>From a complex PMAPI(3) client POV (e.g. pcp-atop), this involves
direct use of the pmStore interface.  From a PMWEBAPI(3) POV it's
likely a "_store" end-point will need to be implemented (I think?
that would seem to fit, from reading the man page & poking at code).
I've not looked into deeper hacking on that aspect yet; figured I'd
check in at this point before starting that for the Vector folk, to
see if anyone objects or has additional ideas...?

Ill send through a working prototype shortly along with a little
test utility (PMAPI, C code) if you'd like to try it out so far.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>