[lxc-devel] lxc-clone rewrite

Christian Brauner christianvanbrauner at gmail.com
Mon Aug 31 19:53:03 UTC 2015


On Mon Aug 31, 2015 at 04:08:33PM +0000, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at ubuntu.com):
> > On Mon, Aug 31, 2015 at 01:43:07PM +0000, Serge Hallyn wrote:
> > > Quoting Christian Brauner (christianvanbrauner at gmail.com):
> > > > On Fri, Aug 28, 2015 at 12:46:17AM +0200, Christian Brauner wrote:
> > > > > On Thu, Aug 27, 2015 at 03:41:03PM -0400, Stéphane Graber wrote:
> > > > > > On Sun, Aug 16, 2015 at 04:46:31PM +0000, Serge Hallyn wrote:
> > > > > > > Quoting Christian Brauner (christianvanbrauner at gmail.com):
> > > > > > > Hey,
> > > > > > >
> > > > > > > I'll leave this to Stéphane, as he's pretty keen on leaving the #
> > > > > > > commands
> > > > > > > low.  As you say we might eventually be able to deprecate
> > > > > > > lxc-clone,
> > > > > > > and
> > > > > > > lxc-copy might eventually be a nice hook for migration.
> > > > > >
> > > > > > That'd be fine with me I think, bonus point if we can somehow merge
> > > > > > lxc-start-ephemeral in there and kill two birds with one stone
> > > > > > (lxc-clone & lxc-start-ephemeral).
> > > > > >
> > > > > > The timeline for this would be having lxc-copy in 1.2 with both
> > > > > > lxc-clone and lxc-start-ephemeral doing arg swapping + re-exec
> > > > > > tricks
> > > > > > with a warning that they'll go away for good in 2.0.
> > > > > >
> > > > > > How does that sound?
> > > > >
> > > > > Sounds good! I'm on it!
> > > > >
> > > > > Christian
> > > >
> > > > In the current python implementation of lxc-start-ephemeral we generate
> > > > a
> > > > pre-mount and post-stop script. The post-stop script seems to be used to
> > > > destroy
> > > > the container. For the rewrite in C and the merge with lxc-clone I
> > > > thought
> > > > about
> > > > using a simple snapshot-clone with c->clone() with a random name, start
> > > > it
> > > > c->start() and when the container is shutdown destroy it with
> > > > c->destroy().
> > > > This seems cleaner to me then generating scripts. Are there any reasons
> > > > to
> > > > not
> > > > do it this way? And if so what would you prefer?
> > >
> > > If you can do this robustly and cleanly then I prefer this.
> >
> > The reason was that the container could be started backgrounded (-d) in
> > which case lxc-start-ephemeral wasn't around anymore to clean things up
> > when the container exits.
> >
> > The post-stop method ensured that the container would be destroyed
> > whenever it finally dies and regardless of how it was killed (either
> > shutdown from inside the container or lxc-stop/lxc-destroy).
>
> Right, so to do this without post-stop we'd probably have to hack a special
> case into the reboot: loop around container-start.  Maybe even hardcode the
> 'transient' case into the lxc_handler struct.  Or just have a 'special'
> post-stop hook (doesn't even have to be a script, just a hard-code value
> checked for before we run the script) telling us 'delete this thing'.
>
> It could end up looking nice, or could end up a mess.  I reserve final
> judgement until there's code :)
Agreed. Let's see how mess-less I can code this.

As long as the container is started in foreground mode the container will be
destroyed regardless of whether it was killed by lxc-stop or shutdown from
inside. The only problematic case is when the container is started daemonized.

I need to think about how to handle that case for a bit. I'd like to code more
than one option I think. Unless there's need for rush. :) Suggestions of course
welcome.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150831/7ec1a25b/attachment.sig>


More information about the lxc-devel mailing list