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

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

Reply via email to