[lxc-devel] Container autostart proposal

[Stéphane Graber]

On 05/28/2013 05:11 AM, Jäkel, Guido wrote:
> 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

So I'd rather not abuse the sticky bit for that kind of thing,
especially as there's no good reason to do so.
We can very simply create a separate state file that's removed on
shutdown, or just use the one we already have (rootfs.hold).

Also as I said in my reply to Natanael, I'm not planning on doing any
dependency resolution in LXC. It's pretty difficult to do so (I'm also
upstream for an init system, so believe me, I know ;)) and a job that's
much better done by existing init systems.

I think using priority + time is enough to deal with most of everyone's
current problems with our startup sequence. Those two keys also allow
someone to build a tool which would do dependency resolution and then
update those fields accordingly, though I still think it'd be best to
just use init scripts for such specific cases.

I also agree with lxc.group needing to be multi-value and we'll need
another multi-value field in the system config to list which groups are
to be autostarted (provided lxc.start.auto is also set for the containers).


Now as for state preservation across reboot, it's not something I'm
particularly interested in so I'm not planning to spend time on this
myself. You're however welcome to contribute to that.

One thing we probably ought to do to simplify any future implementation
of this is make lxc.start.auto an integer instead of a boolean. With values:
 - 0 => off
 - 1 => always auto-start
 - 2 => last state (not implemented initially)

So we'd need a patch that essentially changes the new "-a" option of
lxc-start to also start containers with lxc.start.auto set to 2 as long
as the state file exists in the container's directory.
Similarly the "-a" option of lxc-stop would need to be updated NOT to
remove the state file for containers with lxc.start.auto set to 2.


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