[Devel] lxc userspace tools 0.3.0 released

[Dmitry Mishin]

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.

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.

>
> >>> 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.



-- 
Thanks,
Dmitry.