[lxc-devel] Container autostart proposal

Frederic Crozat fcrozat at suse.com
Tue May 28 09:52:34 UTC 2013


Le lundi 27 mai 2013 à 15:07 -0400, Stéphane Graber a écrit :
> Hello,
> 
> One feature that distros have been hacking together on their side for a
> while is container autostart.
> 
> For 1.0 I'd like us to agree on an upstream implementation of this so
> distros no longer need to carry patches in lxc-destroy/lxc-list/... to
> properly list/remove the autostart flag.
> 
> The current implementation in Ubuntu (and I believe in Debian too) is a
> /etc/lxc/auto/ directory which contains a bunch of symlinks to
> containers to auto-start. The symlinks may point to either the config
> directory or the config file.
> 
> This has been working pretty well with only one known caveat being that
> LXC_CONFIG_FILE as exposed to the hooks will be /etc/lxc/auto/<some
> name>.conf which means that doing a basename on it won't return the
> config directory, which has been a problem with some hooks in the past.
> The use of readlink on top of basename can workaround that problem.
> 
> Another problem with this implementation is that the autostart flag is
> lost when migrating the container to another host. One needs to manually
> remove the symlinks on the source and recreate it on the destination.
> 
> 
> So I therefore have two proposals on how to implement this, let me know
> what you prefer:
> 1)
>  - Keep things as they are in Ubuntu and make that the official way of
> auto-starting containers. Documentating /etc/lxc/auto as the location in
> which people need to place their symlinks.
>  - Update our tools to properly list and destroy those auto-started
> containers.
>  - Extend lxc-start and lxc-stop to allow starting all auto containers
> and stopping all known containers (-a flag would be my suggestion).
> 
> 2)
>  - Quite a bit more complex but more flexible.
>  - Introduce a new lxc.autostart system config option (lxc.conf).
>    This is a boolean turning autostart on/off on a system level.
>  - Introduce a few more container options:
>    + lxc.start.auto => boolean
>    + lxc.start.priority => integer, highest wins
>    + lxc.start.time => integer, time in seconds
>  - Extend lxc-start and lxc-stop to allow starting all auto containers
> and stopping all known containers (-a flag would be my suggestion).
>  - In this mode, lxc-start would sort the containers by priority, then
> start the first one, wait up to lxc.start.time for it to be RUNNING,
> then start the next one, etc...
>  - The defaults would be lxc.start.auto=false, lxc.start.priority=0,
> lxc.start.time=0.
>  - It'd be assumed that only containers in lxc.lxcpath can be autostarted.
>  - This design would also work for unprivileged containers where
> lxc.lxcpath points to the user's home directory, in such case, the
> distros will need to have something call "lxc-start -a" on session open
> and "lxc-stop -a" on session close (or whenever they want).
> 
> 
> While 1) is clearly a lot less pain and much easier for the distros
> already supporting autostart to migrate to, I think there's a pretty big
> benefit in getting 2) as it's more flexible, allows for delayed start
> and supports unprivileged containers.

Of course, presented like that, option 2 sounds better ;)

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE





More information about the lxc-devel mailing list