<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 March 2015 at 09:23, Jäkel, Guido <span dir="ltr"><<a href="mailto:G.Jaekel@dnb.de" target="_blank">G.Jaekel@dnb.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Bostjan,<br>
<br>
I already told my 5ct on this many month ago, but now -- with LXC 1.x -- it might be the time to discuss about it, again.<br>
<br>
<br>
IMHO one want to describe dependencies and it's up to the computer to derive any order from that. It's the same feature as within all the different init systems.<br>
<br>
For a specific container on may want to describe the dependency on others -- in an advanced model as a hard (NEED - MUST be running before us) or soft (USE - will be try to start before us, if not running. But don't care, if this fail) dependency.<br>
<br>
In spite of this is enough to describe the dependency tree, it will be handy if on is able to describe also forward dependencies to other containers by the additional set (BEFORE/AFTER - start us before, if (and only if) the other is actually requested to start) because in absence of this one have to anchor is piece of information not in the scope of the actual container but on other, that may even not exist.)<br>
<br>
>From this, a set dependency graph have to be calculated. Then, independent trees and nodes might be started in any arbitrary order, optional with a configurable parallelism.<br>
<br>
Shutdown of any or all containers should respect the dependency graph in the obvious reverse order -- if some Container is called to be stopped that is NEED by others, this others have to be stopped first -- if just USED, then don't care.<br>
<br>
And as an implementation gimmick, there is an virtual node of dependencies ("ALL") with an implicit NEED of all ("autostart"-marked) Containers and an implicite NEED for this node for every container. This target may be used to start or stop all Containers in the described order.<br></blockquote><div><br></div><div>This is an excellent description of problem at hand.</div><div><br></div><div>Although I can see how one's path frequently leads from simple sequential container startup ordering to dependency-based tree resolution, I do think that simple sequential ordering has its place as one of possible ordering solutions.</div><div>BEFORE/AFTER is fine if you have named containers, but if you just have a bunch of containers that conceptually fall into "dev", "staging" and "production" environments but do not care for one another, I can see how setting lxc.start.order to values "300", "200" and "100" respectively simply solves the question of which containers are more important than others.</div><div><br></div><div>Dependency tree based solution works excellent if you have multiple containers depending on each other (not cyclicly) to run single bigger application. If you have multiple containers that do not relate to each other more than sharing the same LXC host, then simple ordering might be a more appropriate solution.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But the meta question is still: Should this feature be up to LXC or should it be left to the surrounding environment, because every LXC host will already have an full featured init system and it's to set up the startup of Containers in a specific order is as easy as for every other Unix daemon. This also includes different instruments to define what "Container have started" actually mean -- form "successfully spawned lxc-start" up to "a service is ready to work")<br></blockquote><div><br></div><div>lxc-autostart already exists, why not push that implementation to a sensible limit?</div><div>LXC cares about containers, not the services they provide. Thus if dependency tree is implemented in lxc-autostart, LXC should not look further than successfully spawned lxc-start to treat container as running.</div><div><br></div><div>If starting container Z that depend on service Y running in container X is the problem, I see two options:</div><div>1) LXC provides a hook lxc.hook.is-running, which signals if container is fully initialized and running;</div><div>2) leave this to fully featured init system</div><div><br></div><div>Under option 1) there is an important question to be answered: if is-running hook returns false, what does that mean? Do we wait some more? Do we start dependent containers at all, after timeout? Or do we not start them and wait indefinitely? If so, what about host boot-time?</div><div><br></div><div>b.</div><div><br></div></div></div></div>