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