[lxc-devel] lxc_spawn() in lxc_restart()

[Cedric Le Goater]

On 06/09/2010 07:29 AM, Sukadev Bhattiprolu wrote:
> Hi,
>
> The following commit for restart-framework adds a call to lxc_spawn()
> in lxc_restart(). lxc_spawn() creates a container and in the child
> calls the restart plugin (which maps to app_restart() from USERCR)
>
> 	commit 196f1d54cef61534e6f98a47956cc87bffb6152e
> 	Author: Cedric Le Goater<clg at vnet.ibm.com>
> 	Date:   Tue Jun 1 11:44:44 2010 +0200
>
> 	    add restart framework
>
> But if the entire container was checkpointed (as we do in LXC),

I suppose you mean, as in

	http://www.linux-cr.org/git/?p=linux-cr.git

which has nothing to do with LXC.
  
> the checkpoint image already includes a container - So the restart logic
> (in app_restart()) would restart the entire container.
>
> With the above lxc_spawn(), the restarted container would be nested
> insided the container created by lxc_spawn().
>
> Is the lxc_spawn() in lxc_restart() required ?

yes. LXC manages the container and you can't ask LXC to do this task
correctly  if something like C/R crawls behind his back and does
half of the job.

the C/R component is based on the fact that a container exists,
namespaces for identifying and isolating resources. If this C/R
component restarts the container, big troubles are ahead. needless
to say that you're violating a basic law of CS by mixing software
layers, and that you will fall sooner or later in a chicken & egg
problem, very common with C/R.

This is a strong requirement from our POV and our C/R implementation,
which is compatible with other implementation like BLCR


> If some set up needs to be done after app_restart() creates the new
> container,  would adding a callback from app_restart() into LXC be
> sufficient ?  i.e maybe this callback could do some/all of the steps
> that do_start() does ?

I suggest you rewrite lxc_restart() to fit your need, like done in the
previous version  0.6.5, and we'll see then how we could factorize
things to help you.

Cheers,

C.