[lxc-devel] lxc git branch

[Dietmar Maurer]

> 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

sure, I agree on that.

> bring checkpoint/restart on top of lxc. And making the 'exec'
> configurable is a way to organize the code and do some cleanup.

Yes, but the current tty code make c/r impossible, because it uses pty
resources of the host?

> > - for application containers, you need an 'init' anyways?
> 
> If you want to support daemon like sshd, yes. Otherwise it is not
> mandatory.

I thought the current code always starts an dummy init?
 
> > - 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 ?

Yes, that is why we can pass flags to cinit to adjust the behavior.

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

IMHO, this is a debugging feature. And you can also 'tail -f file' to
show
the output of that file ;-)

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

ah, ok.
 
Btw, the current 'lxc-start' is an additinal process, staying around for
the whole 
lifetime of a container. Don't you think we can remove that overhead?
OpenVZ shows
that it is not strictly needed.

- Dietmar