On 05/28/2013 03:14 AM, Natanael Copa wrote: > 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.
I think I'd rather have that as "lxc.group" as it'd probably be used by lxc-ls and a few of the other tools to allow you to list only a group of containers. But yeah, I can see the potential of grouping containers especially in development environments that require multiple containers for a given project. > 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. I have no plan to implement actually dependencies between containers as this indeed quickly becomes a nightmare and is way more suitable for an init system to do. However the implementation of priority + time makes it easy for someone to write a tool generating and updating those two values based on dependencies. FWIW I'm a big supported of designing your services properly so they cope with missing related service and just wait until everything is ready. But I realize not everyone has the time to make sure all their services behave in a sane way ;) > 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) We've got some ways to do that (though not with great filtering) through the API. From the shell, I think you'd need to iterate through the containers and then use something like lxc-config to extract the config keys. That reminds me, lxc-config really should be updated to allow parsing of both a container config and the system config (instead of just the system config as it currently does). > -nc > -- 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
