[lxc-devel] Container autostart proposal

[Natanael Copa]

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

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

The nice thing with this is that it is simple and stupid.
 
> 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
...
> 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.
> 
> Thoughts?

It would be nice to have the concept of groups. Like

 lxc.start.group = default

Then we have an 'lxc-start -a [group]' where you can start all
containers in group 'default' in one shot.

Then I think it would be nice if the init system could take care of
dependency handling and start up delays. Dealing with states,
dependencies and parallel startup can be complicated (think circular
deps, deadlocks etc) and the init system already does all that.

What would be nice though, is some convenient way to fish out the
config options. Like, get me a list of all containers that are in group
'foo'. Get me the value for config option 'lxc.start.wait' for
container 'bar'. (looks like there is a get_config_item for this)

-nc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130528/45fe84b6/attachment.pgp>