Merge pull request #299 from avagin/api-linux

Prepare ground for moving on new API
libcontainer: move Config in a separate package

We are going to import the namespaces package into libcontainer,
so libcontainer should not be imported into namespaces.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
libcontainer: move State in the configs package

We are going to import the namespaces package into libcontainer,
so libcontainer should not be imported into namespaces.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
nsinit: clean up

Signed-off-by: Andrey Vagin <avagin@openvz.org>
linux_container: fork an init process in a new set of namespaces

Use namespace.Exec() and namespace.Init() to execute processes in CT.

Now an init process is actually executed in a new container. This series
doesn't change code about creating containers, it only reworks code according
with new API.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
libcontainer: optimize updateStateFile()

Signed-off-by: Andrey Vagin <avagin@openvz.org>
process: use io.Reader instead of io.WriteCloser for standard fds

Could someone explain why we should close this fds? Usually users
cares about closing them or not.
For example exec.Cmd declares them as io.Reader.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
libcontinaer: use new API in integration tests

Signed-off-by: Andrey Vagin <avagin@openvz.org>
namespaces: combine Process.Env and Container.Env

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Merge pull request #306 from avagin/api-linux-2

Use namespace.Exec() and namespace.Init() to execute processes in CT
nsinit: remove ticks around nsenter

If we really need these command, we need to expand API.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
new-api: return the Running state only if the init process is alive

Signed-off-by: Andrey Vagin <avagin@openvz.org>
new-api: execute a process inside an existing container

A new constructor function (like nsenter) is added in this patch.  This
function gets arguments from environment variables and its behaviour doesn't
depend on a command line arguments.

A program which calls factory.StartInitialization() must import the nsenter
package. It looks ugly, but I don't know another way how to enter into CT from
a go code.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
new-api: clean up startInitProcess()

Signed-off-by: Andrey Vagin <avagin@openvz.org>