[lxc-devel] Container autostart proposal

[Jäkel, Guido]

Dear Stéphane,

To my opinion, we have to deal with two independent things: System crash recovery and container startup/shutdown dependencies

>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.

May I repeat my proposal to (miss-) use the sticky bit (file mode 1000) of the config file as a marker. I would use it to persist the fact that a container is currently up. Therefore, it should be set by an successful lxc-start and cleared by a lxc-stop by default. 

After a system chrash, all containers with such a marker set should be restarted. For the one's with some "autostart" declaration, with conditions derived from this framework ruleset. But event with this framework is unused, also the containers not mentioned here should be brought up again if they were running before. This might be signaled by a special "powercycle"-option for lxc-start. The same option applied to lxc-stop may prevent to clear the running marker. By help of this, a reboot may be keep this flags to let the running containers restart but a shutdown or poweroff action of the host may also keep all containers stopped at next boot of the host.


I vote to use lxc config options to declare the meta information like start timeout. Instead of ordering via a priority number I would strongly prefer to model it with a "needs foo,bar" tag for different reasons: First again the "portability to another host". In addition, it's a canonical description and it's much more easy to insert something or to mention/realize that no order is required.


I also like the idea of Natanael to declare a group that might be used. One should be even able to list more than one group name in the configuration tag because a concrete container may be needed for different sets.

Maybe then a special syntax for the container argument on appropriate lxc command may be used to deals with such a set of containers. Maybe we allow a ','-separated list of names for the -n option. And prefix like '~' means a group name and is expanded by such a list of it's member's names. In addition, '~' may be expanded to all containers and '~~' to all "groupless" containers.


Greetings

Guido