On 4/28/2015 7:18 AM, bougyman wrote:
On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne <avery.p.pa...@gmail.com> wrote:
I guess I don't know what this means, in practice. My child services
generally know about the
parent in their ./run script and the parent (sometimes) has to know
about the children in his
./finish script.
I do the opposite using an optional flag that is initially disabled at
installation. The short version is, using
parent-only-knows-child-needs makes the dependency chains self-organizing.
The long version is that, in supervision-scripts, each service (parent)
has a list of immediate needs to be met (children). It attempts to
start each child in a subdirectory named ./needs (coincidentally, anopa
uses a compatible arrangement with ./needs). Each child is iterated
through and checked to see if it is running; if it is not running, it is
started, and the next child examined, until all children are started.
If all children start, the parent proceeds to start. If a child fails,
the parent writes a message to its log saying "my child X failed" and
proceeds to spawn-loop.
As each child starts, if there is a ./needs in the child, it repeats the
same behavior as the parent, calling other grandchildren and then
eventually starting once all of its own dependencies are running. The
script is the same for parent and children alike, so the behavior is
meant to be consistent. The process is repeated for each grand-child,
great-grand-child, etc. until the lowest dependencies are running,
causing the entire dependency "tree" to be traversed. This also means
the "tree" can be a "chain" or any other arrangement. "Leaf nodes" of
that tree can be called more than once without harm because if they were
already launched elsewhere, the start-up of that node is skipped. And
finally, I don't need to track the entire state of the tree, I only need
to track what children are needed for any given parent, making the
entire thing self-organizing, while keeping it simple.
None of the parents know anything about their children.
I'm just doing it backwards. If I had definitions for postgresql and
pgbouncer, I would only add the following soft links:
/etc/sv/app_which_uses_pg/needs/pgbouncer
/etc/sv/pgbouncer/needs/postgresql
That's pretty much it. Nothing else would need to be added to ./run for
each service.
I'd like to see the difference in a code example. I haven't had a
chance to dig in to anopa yet enough to see how they couple it mouse
loosely. Tj
Here's the current version of run.sh, with dependency support baked in:
https://bitbucket.org/avery_payne/supervision-scripts/src/b8383ed5aaa1f6d848c1a85e6216e59ba98c3440/sv/.run/run.sh?at=default
