[lxc-devel] Container autostart proposal

[Dwight Engen]

On Mon, 27 May 2013 15:07:03 -0400
Stéphane Graber <stgraber at ubuntu.com> wrote:

> 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

I think instead of priority (high -> low), something like sequence (low
-> high) might be more natural (count up instead of down). It is also
more similar to old rc init scripts.

>    + 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.

Yeah I think 2 is much better, more flexible. I like that it keeps a
containers config all in one place which should make migration much
easier.

> Thoughts?
> 
>