Quoting Christian Brauner (christianvanbrau...@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'? -serge _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel