[Lxc-users] start order

[Michael H. Warfield]

On Mon, 2012-12-10 at 08:10 -0600, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at 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 |  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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20121210/480110c6/attachment.pgp>