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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
