[lxc-devel] lxc git branch

Daniel Lezcano dlezcano at fr.ibm.com
Tue Mar 17 12:46:20 UTC 2009


Dietmar Maurer wrote:
>> I will look at making the cinit optional and not correlated to the
>> rootfs.
> 
> It does not makes sense if it is optional, because then you have no way 
> to exec commands inside the container (for example reboot)?

The philosophy of the lxc tools is to be as flexible as possible. You 
see in the code, I tried to have as much as possible everything being 
configurable. And I would like to keep this configurable, especially to 
bring checkpoint/restart on top of lxc. And making the 'exec' 
configurable is a way to organize the code and do some cleanup.

> - for application containers, you need an 'init' anyways?

If you want to support daemon like sshd, yes. Otherwise it is not mandatory.

> - for 'full' containers, you need a way to log init output (really).

Yes, sure. But the logging and the ability to launch commands inside the 
container are different features no ? Maybe someone would like to have 
the init's logs directly displayed on its tty instead of having them 
saved into a file, especially when he is trying to figure out what is 
going wrong when the container boots.

> - and you always want a way to exec commands inside the container.

Not always and that is the point. The liblxc is used with HPC jobs where 
they want only one process inside, so they do lxc-start -n foo myjob.

I know the liblxc is used for security too and admin may not want to 
activate the 'exec' command and keep login the container through the tty.

> and what do you mean by 'not correlated to the rootfs'?

split the code from the setup_rootfs into setup_exec.

Making the 'exec' configurable does not mean it will be disabled, it can 
be enabled by default but definitively we must have a way to disable it.

Having this feature in lxc is a must have and I will certainly keep it 
always enabled for my own configuration, at least to debug my 
applications inside the container with gdb ;)


ps : I cc'ed the lxc-devel@, you should subscribe to the mailing list 
before answering otherwise your email will be ignored.

https://lists.sourceforge.net/lists/listinfo/lxc-devel




More information about the lxc-devel mailing list