Re: [Devel] lxc userspace tools 0.3.0 released

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

Dmitry Mishin wrote:
> On Saturday 18 October 2008 00:42:38 Daniel Lezcano wrote:
>> Dmitry Mishin wrote:
>>> On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
>>>> 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
>>> I mean how it will be handled from configuration layout POV?
>>>
>>>> Do you have an example, an use case for this kind of configuration ?
>>> For example, web server and dns server for the same domain, hosted on the
>>> external node.
>> Ok I see, thanks.
>>
>>> As you mentioned, the goal of this tool is to provide ability for kernel
>>> hackers to test namespaces support in mainstream. Thus it should be
>>> flexible as possible and do not add limitations over current
>>> functionality. Current design of configuration storing is likely to be a
>>> week place in this sense. At least I do not understand yet how namespaces
>>> inheritance could be reflected in it.
>> I don't think it is a current limitation as I shown in the previous
>> example. Not being able to define a configuration for a nested container
>> is not a big issue right now because the nested container are not fully
>> supported (eg. network devices being pushed back to init_net).
>>
>> The configuration storing is I think a good approach and it is not an
>> API like the cgroup, it can be changed at any time. 
> With the respective backward-compatibility or conversion code to be written...

Good point :)