----- Original Message -----
> >> [...]
>
> the env var was actually in response to an anticipated need for PCP
> container meta-data, the most obvious and pressing of which is "am I
> running in a container?". Interesting to note that container meta-data
> has been a hot topic out there in dockerland and upstream have now
> settled on container "labels", which are similar to env-vars but not
> quite the same. See https://github.com/docker/docker/pull/9882
Interesting stuff, thanks for the pointer Mark.
> I don't know how yet, but PCP PMDAs (other than those that are default
> pre-installed) are probably going to need meta-data if they end up running
> in separate containers, if that's how things end up. e.g. maybe to share
> pcp.conf variables and so forth. Perhaps even the default PMDAs should be
> in their own containers and we make use of container linking with the
> pcp-pmcd container? See --link in docker-run(1). A lot of this depends
> on how the pcp packaging re-split works out .. Lukas?
Hmm, I'm not sure there's alot of win to be had from breaking out the default
PMDAs - will end up with alot of packages/containers that everyone needs just
to get started.
The Docker "best-practices" doc describes their recommended ways of sharing
configs between containers (which we're doing now IIRC) - we really need to
start experimenting with layered containers soon, as no doubt more issues
will fall out of doing that.
We also need to get QA going on containers, I immediately ran into some new
issues when I tried that the other day.
> Amongst other things, I think this would allow PMDA containers to talk to
> the pmcd container via private virtual network interfaces set up by the
> container linkage, i.e. yet another pmda-pmcd ipc mechanism. THis should
> help avoid the need for PMDA containers to be ultra-privileged in order to
> access the host network interfaces or pmcd unix domain sockets directly.
>
> Any thoughts?
The platform PMDAs need to be privileged to do what they need to do, and
they always need to be there, so separating them out seems like it will be
a source of more pain (user/admin/qa/upgrade/...) than good.
The main pmcd unix domain socket is for monitoring tools, so perhaps that
will be more fertile ground for container linking?
> > By the way, have y'all considered using the daemons in foreground mode
> > ("pmcd -f" et al.) as the contained pid-1 process, instead of
FWIW, this was the way it started out until we hit several problems with
that simpler approach.
> > container pid-1 would actually exit when the daemon does, [...]
Not sure what code you're looking at, but that *is* what happens already.
cheers.
--
Nathan
|