Re: [Devel] lxc userspace tools 0.3.0 released

[Dmitry Mishin <dim-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>]

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

> The advantage of 
> having a tree file for a container will appear more clear with the
> future functionalities.
>
> If the nested containers become a must-have and asked by people, the lxc
> tools will be changed in this way. We can imagine to do like the cgroup
> and create in the container directory a new container directory to
> reflect the hierarchy and we access a container by doing for example
> "lxc-stop -n foo/bar" (bar is a child of foo).
Unification with cgroups is good idea, IMHO.
 
> We can imagine to 
> implement a fuse for containers and create / destroy when doing
> mkdir/rmdir, as well as create a directory when doing lxc_create.
>
> The configuration could be something like:
>
> Create a nested container with two configuration files:
> 	lxc-create -n foo/bar -f foo.conf -f bar.conf
>
> And so execute:
> 	lxc-execute -n foo/bar /usr/sbin/httpd /bin/bash
>
> will unshare 'foo', exec 'httpd' and so unshare 'bar' (under 'foo') and
> exec 'bash'
>
> Well these are random thoughts... :)
Good thoughts! I need to take a look at cgroups management tools and possibly 
develop something usefull for lxc :)
 
>
> Thanks
>   -- Daniel



-- 
Thanks,
Dmitry.