On Mon, 27 May 2013 15:07:03 -0400 Stéphane Graber <stgra...@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? > > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
