[lxc-devel] Container autostart proposal

[Stéphane Graber]

On 05/28/2013 03:14 AM, Natanael Copa wrote:
> On Mon, 27 May 2013 15:07:03 -0400
> Stéphane Graber <stgraber at 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

-------------- 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/20130528/19bc31cd/attachment.pgp>