On Tue, 28 May 2013 09:57:13 -0400 "Michael H. Warfield" <m...@wittsend.com> wrote:
> 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. I agree, and another reason for not (ab)using the sticky bit is that I don't think it can be done with the atomic properties that file creation provides. > 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@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-devel > ------------------------------------------------------------------------------ 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
