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