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. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers