Script generators are the way I've been leaning.
It's really convenient to have one or more services defined in some kind of structured data format like yaml or json and to then generate and install the service scripts.
I wish there was a standard format to define services so the generator could take one input file and output appropriate service scripts for different process supervisor systems.
Anyone seen any efforts in this direction? Most upstart and sysv scripts have standard boilerplate, so it looks like there are common standards that could be derived.
- John
> On Oct 31, 2014, at 1:05 AM, Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
>
>
> First, I need to apologize, because I spend too much time talking and
> dismissing ideas, and not enough time coding and releasing stuff. The
> thing is, coding requires sizeable amounts of uninterrupted time - which
> I definitely do not have at the moment and won't until December or so -
> while writing to the mailing-list is a much lighter commitment. Please
> don't see me as the guy who criticizes initiatives and isn't helping or
> doing anything productive. That's not who I am. (Usually.)
>
> On to your idea.
> What you're suggesting is implementing the dependency tree in the
> filesystem and having the supervisor consult it.
> The thing is, it's indeed a good thing (for code simplicity etc.) to
> implement the dependency tree in the filesystem, but that does not make
> it a good idea to make the process supervision tree handle dependencies
> itself!
>
> (Additionally, the implementation should be slightly different, because
> your ./needs directory only addresses service startup, and you would also
> need a reverse dependency graph for service shutdown. This is an
> implementation detail - it needs to be solved, but it's not the main
> problem I see with your proposal. The symlink idea itself is sound.)
>
> The design issues I see are:
>
> * First and foremost, as always, services can be more than processes.
> Your design would only handle dependencies between long-lived processes;
> those are easy to solve and are not the annoying part of service
> management, iow I don't think "process dependency" is worth tackling
> per se. Dependencies between long-lived processes and machine state that
> is *not* represented by long-lived processes is the critical part of
> dependency management, and what supervision frameworks are really lacking
> today.
>
> * Let's focus on "process dependency" for a bit. Current process
> supervision roughly handles 4 states: the wanted up/down state x the
> actual up/down state. This is a simple model that works well for
> maintaining daemons, but what happens when you establish dependencies
> across daemons ? What does it mean for the supervisor that "A needs B" ?
>
> - Does that just mean that B should be started before A at boot
> time, and that A should be stopped before B at shutdown time ? That's
> sensible, but it simply translates to "have a constraint on the order
> of the wanted up/down state changes at startup or shutdown". Which can
> be handled by the init and shutdown scripts, without the need for direct
> support in the supervision framework; an offline init script generator
> could analyze the dependency tree and output the proper script, which
> would contain the appropriate calls to sv or s6-svc in the correct order.
>
> - Or does that mean that every time A is started (even if it is
> already wanted up and has just unexpectedly died) the supervisor should
> check the state of B and not restart A if B happens to be down ? What
> would be the benefit of that behaviour over the current one which is
> "try and restart A after one second no matter what" ? If B is supposed to
> be up, then A should restart without making a fuss. If B is wanted up but
> happens to be down, it will be back up at some point and A will then be
> able to start again. If B is not wanted up, then why is A ? The dependency
> management system has not properly set the wanted states and that is the
> problem that needs to be fixed.
> * Supervisors currently have no way of notifying their parent, and they
> don't need to. Their parent simply maintains them; supervisors are pretty
> much independent. You can even run s6-supervise/runsv without s6-svscan/
> runsvdir, even if that won't build a complete supervision tree. The point
> is that a supervisor maintains one process according to its wanted state,
> and that's it. (With an optional logger for runsv.) Adding a notification
> mechanism from the supervisor to its parent (other than dying and sending
> a SIGCHLD, obviously) would be a heavy change in the design and take away
> from the modularity. It can be done, but not without overwhelming benefits
> to it; and so far I've found that all the additional stuff that we might
> need would be best handled *outside of* the supervisors themselves.
>
> The more I think about it, the more convinced I am that script generators
> are the way to go for dependency management, and service management in
> general. Script generators can take input in any format that we want, and
> output correct startup/shutdown sequences, and correct run scripts, using
> the infrastructure and tools we already have without adding complexity
> to them. It's something I will definitely be looking into.
>
> --
> Laurent
Received on Fri Oct 31 2014 - 09:40:54 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:18 UTC