[lxc-devel] lxc-clone rewrite

Fri Sep 4 17:11:14 UTC 2015

On Fri, Sep 04, 2015 at 04:21:42PM +0200, Christian Brauner wrote:
> On Fri, Sep 04, 2015 at 02:04:29PM +0000, Serge Hallyn wrote:
> > Quoting Christian Brauner (christianvanbrauner at gmail.com):
> > > On Mon, Aug 31, 2015 at 09:53:03PM +0200, Christian Brauner wrote:
> > > > 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.
> > > I'm currently in favour of the lxc.hook.post-stop version for daemonized
> > > containers. The rest means fiddling with a lot of the api-functions for the
> > > a rather special case. But there are two things I would like to have input
> > > about:
> > > 
> > > 1) Should we register ephemeral clone-snapshots in the lxc_snapshots file of the
> > >    original container? (I would think not.)
> > 
> > If for instance it is a overlayfs based snapshot, and you allow the parent
> > to be deleted, then the ephemeral container will misbehave.  I'm pretty
> > sure that's the case now and I haven't heard any complaints, but it is
> > non-ideal.
> > 
> > > 2) Should we have an additional state TRANSIENT in addition to RUNNING,
> > >    STARTING, etc.?
> > 
> > What exactly would it mean?  STARTING is already inherently TRANSIENT.  Would
> > TRANSIENT mean 'building but not yet starting'?
> I was unclear. TRANSIENT or EPHEMERAL in the sense of "this is a running
> container but it will be deleted once it is shutdown". So when you do work on a
> container and you're unsure whether it is an ephemeral container you could check
> with lxc-info -n NAME and see TRANSIENT or EPHEMERAL and know "this thing is
> going to be deleted when I shut it down."

It seems to me like this has the potential to break a fair amount of
existing tools which wait for "RUNNING" before interacting with a
container. If we were to have multiple "RUNNING" equivalent state, we
ought to add a new exported function that'd check whether the container
is running regardless of the state's name but requiring the use of this
would only be possible when we break backward compatibility (so LXC
2.0).

I suspect a cleaner way would be to have a config option for ephemeral
containers, something like lxc.ephemeral=1 that will cause LXC to
destroy the container when it dies and can be used by API clients to
query whether a container is ephemeral.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150904/553d9241/attachment.sig>