Namespacing about lmctfy HOT 12 CLOSED

We are working on the namespaces spec. It would be similar to resource limits but more restrictive in terms of nesting. We are trying to get other resources merged in first. Examples and documentation to follow soon.

from lmctfy.

Closing. It's mentioned in the roadmap.
We'll put the spec up soon.

We are also open to accepting implementation patches :)

from lmctfy.

Before anyone runs out to implement namespaces, or any other major feature,
I hope they talk to us to work out design :) I know that is a bit
idealistic...

On Thu, Oct 3, 2013 at 8:44 AM, Rohit Jnagal [email protected]:

Closing. It's mentioned in the roadmap.
We'll put the spec up soon.

We are also open to accepting implementation patches :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-25631828
.

from lmctfy.

Any updates on namespaces?

from lmctfy.

As of 0.4.5 we have support for namespaces. There is still some on-going work in the area for full support. But basic support exits. Once we have full support we'll close this issue.

from lmctfy.

I notice there's now a nscon-tool. Is there any information about how you
are supposed to use it? Should I use "nscon create" inside a container?

// Magnus Holm

from lmctfy.

nscon is an implementation detail of how we setup namespaces. You certainly can use it by itself but I'd recommend against it.

To enable namespaces what you're interested in taking a look at is the VirtualHostSpec in the ContainerSpec. Once you set that lmctfy will create a set of namespaces as part of the container.

For example:

$ lmctfy create test "virtual_host:{}"

Creates a container with PID and mount namespaces (and no isolation since we didn't specify CPU or memory). Then we can run bash inside:

$ lmctfy run test /bin/bash

You'll note that the only other process in the container is lmctfy-nsinit. Its somewhat hard to configure additional namespaces and we're working on getting all those enabled in the coming weeks. Is there any particular namespace or usecase you're interested in?

from lmctfy.

My use case is a Docker-like system where each container can have their own root filesystem.

from lmctfy.

In that case you'll definitely be interested in using a Virtual Host. The main piece that is missing there is related to the filesystem (the actual chroot/pivot_root). That should be ready next week.

from lmctfy.

Hey Victor could this be used for a Docker execution driver?

On Thursday, May 1, 2014, Victor Marmol [email protected] wrote:

In that case you'll definitely be interested in using a Virtual Host. The
main piece that is missing there is related to the filesystem (the actual
chroot/pivot_root). That should be ready next week.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-41916904
.

from lmctfy.

There is actually a PR for that :)

moby/moby#4891

We'd probably need to rebase it since the execdriver interface has changed a bit, but that PR has probably 80% of the Docker feature set through lmctfy.

from lmctfy.

nice :)

On Thu, May 1, 2014 at 10:56 AM, Victor Marmol [email protected]:

There is actually a PR for that :)

moby/moby#4891 moby/moby#4891

We'd probably need to rebase it since the execdriver interface has changed
a bit, but that PR has probably 80% of the Docker feature set through
lmctfy.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-41936137
.

from lmctfy.