Allow the namespace path to be container ID

[laijs]

In numerous cases, we need to share the container's namespace with
an existing container. In these cases, we have to resolve the namespace
file step by step. For example, the docker resolves it from the
information of the target container in several steps and saves it to the
config (now it is in-memory config, it will be runtime.json in future).
We can move the resolving operation to the oci implementations
and allow the namespace path to be container ID in the spec.

Reasons:

• it really repsents "sharing the namespace with existing container".
  (it is the most important reason.)
• the administrator writes the runtime.json much conveniently and
  less error. And it is better readability and the administrator
  is easier to check the runtime.json which is written by himself
  or by other human or by other tools.
• we may have more orchestra tools than oci implementations,
  the resolving operation is better in implementations than
  in the tools.

Signed-off-by: Lai Jiangshan jiangshanlai@gmail.com

[philips]

I really don't want to have magic resolution in the runtime.json like this. If we consider this feature we should have the runtime resolve the naming.

[wking]

This sounds useful, but I'd turn it around. Instead of making it a
lookup-time thing, you could make it creation-time thing with a
pre-start hook like:

#!/bin/sh
STATE=$(cat) &&
PID=$(echo "${STATE}" | jq -r .pid) &&
ID=$(echo "${STATE}" | jq -r .id) &&
DIR="/run/opencontainer/containers/${ID}/ns" &&
mkdir "${DIR}" &&
for NAMESPACE_PATH in "/proc/${PID}/ns/"*
do
NAMESPACE=$(basename "${NAMESPACE_PATH}") &&
touch "${DIR}/${NAMESPACE}" &&
mount --bind "${NAMESPACE_PATH}" "${DIR}/${NAMESPACE}"
done

Then you could use:

"path": "/run/opencontainer/containers/{container-id}/ns/{namespace}"

in another container's runtime.json to join any of the initial
container's namespaces.

[mrunalp]

@laijs I agree with @philips. This sounds like a problem that can be solved using higher level tooling that generates the correct values in your runtime.json

[crosbymichael]

Ok, lets close this one seeing that higher level tooling can generate these paths based on container IDs

[wking]

On Thu, Oct 22, 2015 at 04:16:29PM -0700, Michael Crosby wrote:

Ok, lets close this one seeing that higher level tooling can
generate these paths based on container IDs

We should probably start collecting a list of these punted features,
so we can point people at a single document for out-of-scope features
(ideally with pointers to the higher-level tooling that covers that
use-case). I'm happy to write up something along those lines if that
sounds useful, just tell me where you want it.