[lxc-devel] Container autostart proposal

Mon May 27 19:22:01 UTC 2013

On 05/27/2013 03:07 PM, Stéphane Graber 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
>    + 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...

Oops, that part ended up not matching my initial thought ;)

So please ignore lxc.start.time and let's instead talk of lxc.start.wait.

lxc.start.wait would be a post-start delay applied after the container
reaches RUNNING state.

This value should ideally be an estimate of the container's boot time
and can be used to reduce the load at boot time caused by multiple
containers starting in parallel. It can also be used to create some kind
of dependency chain when combined with lxc.start.priority so that
containers that depend on each other can be started in the right order.

I remember someone working on a new STARTED state or similar a while
back which the container could move into by communicating back to lxc
through a fake /dev device (or some other kind of socket).
If we have such a facility, then moving into STARTED state should
interrupt the wait for lxc.start.wait.

To be clear, lxc.start.wait should act as either a fixed amount of time
to wait post-start OR as the timeout for the STARTED state should it exist.

>  - 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?
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 

-- 
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/20130527/feb95d22/attachment.pgp>