Re: [Devel] lxc userspace tools 0.3.0 released

[Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>]

Dmitry Mishin wrote:
> On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
>> Dmitry Mishin wrote:
>>> Hi, Daniel!
>> Hi Dmitry ! good to see you again :)
> Thank you ! :)
> 
>>> I studied a bit lxc tools and have a couple of questions. Could you
>>> answer them?
>> Of course I can :)
>>
>>> 1)  Why did you chose such way of a container's configuration storing?
>>> IMHO, configuration in one file is better, because this file will be
>>> small and could be easily mmap'ed for the following operations instead of
>>> multiple readdir() and filesystem lookups.
>> I wanted to have the configuration easily hackable, so you can edit
>> directly the files inside the directory. For example, if you remove the
>> network directory, when you will start the container, the network will
>> not be unshared. If you have a single file, that will be more difficult
>> to edit especially if it is a binary file.
>>
>> The container tree contains more than the configuration file, for
>> example, it contains some runtime information.
>>
>> It is true having a mmapped configuration is more efficient but it is
>> just for container startup, and there are not thousand of files. The
>> application running inside the container is not impacted.
> OK, but what if I need some namespace to be shared between containers?
> How it will be handled? For example, CT 1 and CT 2 need to share network 
> namespace, but keep it separated from host one.

I think that can be solved by nested container, a container 1, unsharing 
the network, and inside create 2 containers without unsharing the network.

Example:
	in a script called myscript.sh:
		#!/bin/bash
		lxc-execute -n ctr1 echo "hello1" &
		lxc-execute -n ctr2 echo "hello2"
	
	in the shell:
	lxc-create -n mynetwork -f myconf
	lxc-execute -n mynetwork ./myscript.sh


Do you have an example, an use case for this kind of configuration ?

>>> 2) why did you chose cvs as VCS? Git is more common and convenient for
>>> distributed development...
>> The lxc userspace tool is a low level component I wrote to play with the
>> container, and especially to facilitate the kernek hacking. The lxc
>> kernel website is at lxc.sourceforge.net, so logically I put this
>> component at the same place. Unfortunately the sourceforge website does
>> not provide the services for git tree, only CVS/SVN. But I agree 100%
>> with you, I would have definitively preferred to use git.
> Worth to create it at git.openvz.org?

Yep, why not. I have to think about that.