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