[lxc-devel] Container autostart proposal

Stéphane Graber stgraber at ubuntu.com
Mon May 27 19:07:03 UTC 2013


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.

Thoughts?


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130527/da85c253/attachment.pgp>


More information about the lxc-devel mailing list