[lxc-users] Autostart: container ordering for various multi-container operations

[Bostjan Skufca]

On 5 March 2015 at 09:23, Jäkel, Guido <G.Jaekel at dnb.de> wrote:

> Dear Bostjan,
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.)
>
> 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.
>
> 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.
>
> 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.
>

This is an excellent description of problem at hand.

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.
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.

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.


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")
>

lxc-autostart already exists, why not push that implementation to a
sensible limit?
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.

If starting container Z that depend on service Y running in container X is
the problem, I see two options:
1) LXC provides a hook lxc.hook.is-running, which signals if container is
fully initialized and running;
2) leave this to fully featured init system

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?

b.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150306/91049475/attachment.html>