On 06/01/2015 22:17, Avery Payne wrote:
> And there's the rub. I'm at a crossroad with regard to this because:
>
> 1. The user wants service A to run.
> 2. Service A needs B (and possibly C) running, or it will fail.
>
> Should the service fail because of B and C, even though the user wants A up,
>
> or
>
> Should the service start B and C because the user requested A be running?
My answer is: there are two layers, and what to do depends on what exactly
the user is asking and whom it is asking.
If the user is asking *A* to run, as in "s6-svc -u /service/A", and A needs B
and B is down, then A should fail.
If the user is asking *the global state manager*, i.e. the upper layer, to
change the current state to the current state + A, then the global state
manager should look up its dependency database, see that in order to bring up
A it also needs to bring up B and C, and do it.
If you have a global state manager, that is the entity the user should
communicate with to change the state of services. It is the only entity
deciding which individual service goes up or down; if you type
"s6-svc -u /service/A", the state manager should notice this and go
"nope, this is not the state I've been asked to enforce" and bring down
A immediately. But if you tell it to bring A up itself, then it should do
whatever it takes to fulfill your request, including bringing up B and C.
This is Unix: for every shared resource, there should be one daemon which
centralizes access to that resource to avoid conflicts. If you want service
dependencies, then the set of service states becomes a resource, and you
need that centralization.
I'll get to writing such a daemon at some point, but it won't be
tomorrow, so feel free to implement whatever fulfills your needs:
whoever writes the code is right. I just wanted to make sure you
don't start an underspecified kitchen sink that will end up being a
maintenance nightmare, and I would really advise you to stick to the naive,
dumb approach until you can commit to a full centralized state manager.
--
Laurent
Received on Tue Jan 06 2015 - 21:51:05 UTC