On Mon, 2012-12-10 at 08:10 -0600, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > There has been very little discussion in the main project over how to > > manage autobooting containers (or maybe I've missed it). Maybe it's > > time we had it. > > > > What I do now is specific to my constellations of 6 lxc hosts (about 4 > > dozen guest containers) at two sites. I would personally prefer this > > sort of information to be contained in the individual container config > > files, ala OpenVZ and Linux-Vservers, without creating an entirely new, > > distribution specific, configuration file. > > > > Primary argument with having it contained within the container config > > really concerns migration. When I migrated a container from one host to > > another host in the same cluster, if all that information is in the > > container config, it follows along. If you bury it in a common config, > > you then have to edit those configuration files on both the servers (the > > throwing and the catching) in order to properly complete the migration. > > I don't like that idea at all. > > Buried in a config, but it could be exposed by lxc-info so it wouldn't > be so bad. Though I guess it could be an issue for boot-speed fanatics > who want to minimize random disk access during boot.
I won't say that I'm a boot speed fanatic but I can be (more than) a little OCD with regards to getting certain critical containers up as quickly as possible even where other delays dominate. > A simple > LXC_AUTOSTART=no default would probably make them happy (how many ppl > really want autostart, and of those, how many of the systems they boot > every day do they want it enabled on?) Systems of this sort should not be be booted "every day". My test systems - sure. My production systems - Hell NO! My monster host at my colo site, berserker-base, was recently booted after upgrading a root kernel in the host system and a distro upgrade. It had been up over 500 days. It took hours to fsck the various file systems just to boot and some critical containers were down that entire time (I do have my authoritative name servers scattered between multiple hosts with nice long TTLs and I work with Hurricane Electric for slaves so I had no disruption in service). But it had close to 3 dozen containers. It took only a minute or so to bring them up, once the host was up, so, against the hours of fsck, the minor difference between one machine starting before another was a drop in the bucket, I will admit. Still, I wanted those name servers up first. :-) They can slow the other containers down if the other containers need DNS services that these provide. There are dependencies in there for both DNS and routing. Here's my problem. System takes 3 hours to fsck those file systems. I still have to remember to come back to it once it's fully booted and make sure those critical containers get booted up. Yes, I need autoboot badly there. I do get distracted and I do forget. It's happened more than once that someone has called me on the phone asking why there system is down (I have a dozen or so friends with playgrounds I host) and I realized I had gotten distracted and forgot to finish firing everything up. Boot order is less important to me than simply having raw autoboot. I have a script but it's currently run by hand. I always meant to turn it into an init script but hadn't. > It'd be great to have distro-independent boot startup and ordering built > in, so that distros don't have to roll their own. Sounds like you all > have some great ideas so I'll look for patches :) > What I think would be great is > 1. lxc.conf updates to indicate autostart delay and order or > dependencies This sounds reasonable for global configurations. I think providing a container by container delay may be a case where the precision is exceeding the accuracy and may be entirely way too much overkill so a global in lxc.conf is reasonable. I still like having the autoboot option and/or priority in the individual container configs though, since it really is container specific. Maybe there's a way to adapt to both paradigms... Give one a preference. I think I could make that work. > 2. an lxc command to spit out containers which should be started, > in order (to loop over) Ooooo.... I LIKE that idea. I hadn't thought of that! That makes a lot of sense. Something like lxc-boot where you pass it a level number (0 for manual and 1 for boot maybe) and it passes back to you a list of containers that need to be booted to meet the criterion (priority) and in the order they should be booted. That would simplify what I'm doing now... It's really almost a spin on the idea of lxc-ls only you list them (the ones that need booting) out in boot order. > 3. lxc-info update to optionally list that information > 4. could package sysvinit, upstart, and systemd templates. I'll look at the Fedora / RHEL / CentOS / SLS angle. I need to get more into systemd anyways (cough cough)... Someone else would need to field the SUSE, Slackware, Arch, Ubuntu stuff... We do have the case with the current Ubuntu stuff, though, where it will start containers using config files that have not been run through lxc-create. Is this something we want to support??? Is it too great a burden to say no? I'm not totally sure I'm fond of that /etc/lxc/auto solution but it is a solution. > -serge 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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
