[Lxc-users] start order

[Serge Hallyn]

Quoting Jäkel, Guido (G.Jaekel at dnb.de):
> 
> >On the other hand, I *do* also feel that any services on the containers
> >ought to be robust to unavailability, so that startup order should not
> >matter.
> 
> Dear Serge,
> 
> yes - it's Xmas time, bells are ringing and all is warm and bright. ;)

:)

> Unfortunately, it matters to the greater part of software. The better on will run into an (comparable short) timeout and fail in a defined way on startup. The other part will run but fail later or have lacks in an functional way without recovering from it if the preconditions become available. And all of us will have seen some software which need some later unused requirements.
> 
> Why we should need the similar mechanisms in all of the system init frameworks, if every part of the puzzle will just well-behaved wait until all preconditions are fulfilled ... 

And I don't claim that it's up to lxc to force users to become cloud-safe,
though I do point out that juju with its relations seems to achieve this
just fine - but that's with the help of cloud-init...  I'm digressing.

Let's assume that we definately want to provide dependency-based container
startup.  That brings up some questions (some sounding familiar from
Upstart discussions)

	1. How do we express that container c depends on containers a and b?
	2. How do we decide whether containers a and b are ready?
	3. For complicated dependencies, how do we structure the lxc.init
	   script to do the right thing?
	4. In your farm environment like yours, do we (and if so then how do
	   we) express containers on another host?

You know, off the top of my head (meaning there are probably major flaws)
here is another idea.  We support lxc.hook.start hook scripts today, which
are executed in the container before /sbin/init is run.  The containers
which have dependencies could use lxc.hook.start scripts which wait until
the depended-upon ip addresses are up before proceeding to start /sbin/init.

-serge