Re: thoughts on rudimentary dependency handling

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Tue, 6 Jan 2015 09:46:29 -0800

On Tue, Jan 6, 2015 at 8:52 AM, Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:

>
> I'm not sure exactly in what context your message needs to be taken
> - is that about a tool you have written or are writing, or something
> else ? - but if you're going to work on dependency management, it's
> important that you get it right. It's complex stuff that needs
> planning and thought.


This is in the context of "service definition A needs service definition B
to be up".


>
> * implement a ./needs directory. This would have symlinks to any
>> definitions that would be required to run before the main definition can
>> run. For instance, Debian's version of lightdm requires that dbus be
>> running, or it will abort. Should a ./needs not be met, the current
>> definition will receive a ./down file, write out a message indicating what
>> service blocked it from starting, and then will send a "down service" to
>> itself.
>>
>
> For instance, I'm convinced that the approach you're taking here actually
> takes away from reliability. Down files are dangerous: they break the
> supervision chain guarantee. If the supervisor dies and is respawned by
> its parent, it *will not* restart the service if there's a down file.
> You want down files to be very temporary, for debugging or something,
> you don't want them to be a part of your normal operation.
>
> If your dependency manager works online, you *will* bring services down
> when you don't want to. You *will* have more headaches making things work
> than if you had no dependency manager at all. I guarantee it.


I should have added some clarifications. There are some basic rules I'm
using with regard to starting/stopping services:

1. A service can ask another service to start.
2. A service can only signal itself to go down. It can never ask another
service to go down.
3. A service can only mark itself with a ./down file. It can never mark
another service with a ./down file.

That's it. Numbers 2 and 3 are the only times I would go against what you
are saying. And since the only reason I would do that is because of some
failure that was unexpected, there would be a good reason to do so. And in
all cases, there would be a message output as to why it signaled itself
back down, or why it marked itself with a ./down file. The ./down file is,
I think, being used correctly - I'm trying to flag to the sysadmin that
"something is wrong with this service, and it shouldn't restart until you
fix it".

I'm sorry if the posting was confusing. Hopefully the rules clarify when
and how I would be using these features. I believe it should be safe if
they are confined within the context of the service definition itself, and
not other dependencies. If there is something to the contrary that I'm
missing in those three rules, I'm listening.
Received on Tue Jan 06 2015 - 17:46:29 UTC