[lxc-devel] Container autostart proposal

Tue May 28 13:57:13 UTC 2013

On Tue, 2013-05-28 at 09:29 -0400, Stéphane Graber wrote: 
> 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).

I have to also concur with this.  I would be appalled and adamently
opposed to overloading the stick bit with that sort of functionality
that could have untold side effects.  It would end up being poorly
documented, confusing and very misunderstood.  We've seen that sort of
thing in the Samba project.  A state file (similar to the .hold file) in
the container's management directory makes vastly more sense.

Regards,
Mike

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

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!