On 03/18/2015 05:15 AM, Frank Ch. Eigler wrote:
Nathan Scott <nathans@xxxxxxxxxx> writes:
Nathan Scott (6):
docker: switch to using Marks env var suggestion
[...]
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
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?
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?
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
inventions such as pmsleep? Something like the patches below
[1] or even [2] (untested!).
Beyond removing an unnecessary part, another benefit would be that the
container pid-1 would actually exit when the daemon does, so that the
orchestrator could possibly restart the thing.
It's unclear to me just how important the pid-1 requirement is and how
signals and child pids are managed by orchestrators .. I assume the
daemon waits for pid-1 and pid-1 is responsible for it's own children.
At the very least, I guess it should work with the prevailing "docker run
--restart" policy to apply when a container exits (no, on-failure[:max-retry],
or always).
Cheers
-- Mark
|