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 (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'? > 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
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
