On Wed, 2013-05-29 at 18:31 +0200, Harald Dunkel wrote: > Hi folks, > AFAICS I have to list all containers to be started at boot > time in /etc/lxc/auto using symlinks pointing to the > config files. Problem: /etc is a local file system.
> For a HA solution you usually have some kind of "network" > device/filesystem providing the resources to manage, e.g. > a DRBD or iSCSI partition holding a set of LXC config files > and rootfs directories. In case of a hardware failure you > change the run level on a hot standby host, some init script > mounts the LXC partition, and LXC's init script is supposed > to start the containers for this run level. Unfortunately > the symlinks in /etc/lxc/auto have been lost together with > the old host. Hopefully you see the problem. > Instead of symlinks in /etc/lxc/auto I would suggest to set > the config files to executable as an autostart flag. Thats > very easy to set, test and clear, _and_ it is part of the > filesystem providing the LXC config file. I would strongly disagree with this proposal for several reasons. 1) We have a proposal for a set of start parameters contained in the configuration file itself which can handle this. 2) It's inappropriate (and often non-portable) to overload permission bits for features for which they were not designed. We just discussed this wrt using the sticky bit for retaining the container run-state for auto reboot state control. 3) The file itself is not executable and using it in this way would violate established file permission semantics. Executing the file would / should fail but it's an ugly failure and including the conventional #!/.../lxc-start would not be a good solution. 4) There are potential side effects relating to selinux and/or apparmour which would have to be explored (anytime you're playing silly buggers with permissions). 5) It has none of the granularity of groups and priority (boot order) that are provided for in other proposals. It doesn't even provide for the possibility of prioritized ordering through prefix in the symlinks as as suggested by Serge ages ago when this was last brought up before the current round or proposals. > Just a suggestion, of course. I think the current proposal for startup parameters contained in the file will do what you want to do and in a way that can be transported between systems, is portable between (differing) systems, and has a fine grained control over boot ordering and grouping. Please refer to the current thread in the list wrt "Container autostart proposal V2". If you haven't been / are not a subscriber (I saw the moderation request come through saying you weren't), please check it out in the archives and please join us for the discussion. This is an active discussion on the agenda. You're very timely in that regard. > Regards > Harri Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
