Hello, I think I can answer part of this, even though I am not an Ubuntu user... Maybe this will prompt some more generic discussion over autoboot of containers and automatic lxc startup on some distros where it's lacking.
On Fri, 2012-12-07 at 23:45 +0100, Papp Tamas wrote:
> hi All,
> Regarding the bug #1087765 is there a way in Ubuntu to specify the starting
> order of containers?
> I this this code in /etc/init/lxc.conf:
> for f in /etc/lxc/auto/*; do
> c="$(basename $f .conf)"
> lxc-info -n $c 2>/dev/null | grep state | grep -q "RUNNING" ||
> lxc-start -n $c -f $f -d
> done
> Why are they started with '-f <config file>'?
> Why not just 'lxc-start -n $c -d'
Big difference between "-f <config file>" and "-n $c -d" has to do with
whether the container had been previously "created" with lxc-create and
whether its configuration file exists in /var/lib/lxc/${c} or not. It's
possible to drop a full configuration file there into /etc/lxc/auto and
not have it exist in /var/lib/lxc and then "-f <config file>" would work
while "-n $c -d" would fail. That would be my guess there.
> I think it would be simple using a config file with the order of the specific
> or with all the
> container names.
> Something like this:
> /etc/lxc/order.conf:
> dnsserver
> ldapserver
> puppet
On the boot order... That's an interesting question. I've worked with
linux-vservers and OpenVZ in the past and neither of them give you that
fine grained of an autoboot control (OpenVZ only has numerically
identified containers).
I really don't like this particular option. I'm personally against the
"pile it all in one file" kind of thing and would rather add container
specific options (to autoboot at boot time and at what priority) into
the individual container configs.
> If exists, these containers would be started started first.
> Maybe specifying delay would also be useful?
> Eg:
> /etc/lxc/order.conf:
> dnsserver:15
> ldapserver:30
> puppet:15
I've been imitating the way OpenVZ does this (on Fedora) by adding some
parameters in the lxc configuration files like this:
--
# High level script control management...
lxc-boot.onboot = yes
lxc-boot.disabled = false
lxc-system.description = "Alcove system"
--
Then my script can make that determination just by going
through /var/lib/lxc/*/config looking the "onboot" parameters. A
priority or order or phase could be added in there like that too.
Unfortunately, with my setup for Fedora, I would have no allowance for
containers that were not registered using lxc-create, like the Ubuntu
setup does. That's worth a thought too, I suppose. I'll have to think
about that, particularly in light of some of what I was hearing on the
-devel list of some changes in the behavior of lxc-destroy.
To add priority and delay (and I kinda like that idea of delay... I
don't have that now...), one could change what I had to and
lxc-boot.autoboot = n where, if n > 0 it specifies a priority or
ordering. [n == 0 would be no-autoboot and n < 0 would be disabled
entirely, meaning manual boot from the init script would be refused
unless overridden.] You could do a simple grep and sort on priority and
then container name for the ordered list of containers to start.
Anything within the same numerical value would be sorted by name -
present behavior. Delay would be a separate parameter read and
processed when starting the container under autoboot. This is only
slightly more complicated than the existing process you're describing
above.
So, you might replace what I had above with something like this in each
configuration file...
# lxc-boot.boot...
# =0 => Do not boot automatically
# >0 => Boot order/phase/priority
# <0 => Disabled
lxc-boot.autoboot = 0
lxc-boot.delay = 2
lxc-system.description = "Alcove system"
[I use the system description stuff in some other listing scripts and it
corresponds to a similar OpenVZ parameter.]
Right now, that BSD style Ubuntu setup seems Ubuntu package specific. I
don't see it in the main lxc project nor do I see any sort of
Fedora/RHEL/CentOS/SLS / any other rpm based distribution SysV init
script present (and we really could use one).
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.
> Where numbers mean secundums, eg. dns server receives 15 secundums to startup
> properly.
>
> Essential services would be working before anything else and users would be
> happy:)
>
>
> What do you think about that?
>
> Thanks,
> tamas
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
