----- Original Message -----
> > Having recently looked into the requirements of supporting the Linux
> > kernel container technologies, I propose here an extension to the
> > way in which pmcd operates. [...]
>
> Looks good. It sounds like a meta-pmcd kind of like inetd, launching
> pmcds on demand, nailing some of them into containers if desired.
Eh? I'm not sure you read the same RFC I wrote! But I'll happily take
the "Looks good" part. :)
In this cunning plan, there is only one pmcd, as now, and it has only
one helper co-process which provides services (in particular, it serves
namespace file descriptors) to the other pmcd (IOW to DSO PMDAs) and to
process PMDAs that export data that is affected by specific namespaces.
Its a simple isolation of those parts requiring elevated privilege, and
ensures those parts are at arms length from network facing parts with a
simple, well-defined interface.
This is a small, incremental step that solves a specific problem (or 3),
not a brain transplant for pmcd. You may be seeing it through the eyes
of your plan from long ago to make pmcd like inetd & be able to relaunch
itself in the event "something" fails? It is not that at all - it's a
far simpler concept. I'm not overly fond of forking one pmcd (+ all of
its PMDAs) per-container and definitely not on-demand. That'll quickly
fly against Ken's "we're part of the solution, not part of the problem"
philosophy IMO.
( We should make that the official PCP mantra, BTW! )
Care needs to be taken to not add processes to a container, as there are
are both container lifecycle issues and resource accounting issues there.
Some PMDAs also need to be the only process consuming a source of data,
so we'd soon get into territory where the many pmcd processes need to be
using different configuration files... the stuff of nightmares ...but,
we have discussed this all before, many moons ago.
Indeed, I envisage numerous issues with the pmcd-as-inetd approach - but
if you do feel strongly its worth proceeding in that direction, please
write it up & send out an RFC so we have a complete description of the
problem + proposed solution? At the moment I'm second-guessing what you
might be thinking, which is going to have us on different wavelengths -
talking past each other for sure.
cheers.
--
Nathan
|