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.


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


Greetings

Guido

>-----Original Message-----
>From: lxc-users [mailto:lxc-users-boun...@lists.linuxcontainers.org] On Behalf 
>Of Bostjan Skufca
>Sent: Wednesday, March 04, 2015 8:30 PM
>To: LXC users mailing-list
>Subject: [lxc-users] Autostart: container ordering for various multi-container 
>operations
>
>Hi there,
>
>I would like to open a discussion about container ordering regarding to 
>lxc.start.order and lxc-autostart operations.
>
>Currently, let's presume that pull request https://github.com/lxc/lxc/pull/461 
>is merged and that containers start in
>ascending lxc.start.order fashion.
>
>This makes sense for the following multi-container operations:
>- start
>- reset <--- this may be done in any order actually
>
>What about multi-container shutdown?
>
>So, I would like to know what is your opinion about what feels more natural to 
>you:
>
>a) containers are shut down in the same order as they are started
>b) containers are shut down in reverse order regarding to their startup order
>c) should there be a separate lxc.stop.order setting?
>d) something else?
>
>b.
>
>
>PS: My preference would be to perform shutdown in reverse order, if there is 
>no lxc.stop.order setting (implemented or set).
>

_______________________________________________
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Reply via email to