Re: thoughts on rudimentary dependency handling

From: John Albietz <inthecloud247_at_gmail.com>
Date: Tue, 6 Jan 2015 12:30:53 -0800

"Down by default" makes sense to me and will be a great feature.
I think that having it will require all services to have a 'down' script
that defines how to make sure that a service is actually down.

I wonder if this will help address a common situation for me where I
install a package and realize that at the end of the installation the
daemon is started using upstart or sysv.

At that point, to 'supervise' the app, I first have to stop the current
daemon and then start it up using runit or another process manager.

Otherwise I end up with two copies of the app running, with only one of them
being supervised.

John Albietz
m: 516-592-2372
e: inthecloud247_at_gmail.com
l'in: www.linkedin.com/in/inthecloud247

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

> On 06/01/2015 18:46, Avery Payne wrote:
>
>> 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.
>>
>
> So does number 1.
> When you ask another service to start, you change the global state. If
> it is done automatically by any tool or service, this means the global
> state changes without the admin having requested it. This is trying to
> be smarter than the user, which is almost always a bad thing.
>
> Number 2 is in the same boat. If the admin wants you to be up,
> then you can't just quit and decide that you will be down. You can't
> change the global state behind the admin's back.
>
> Number 3 is different. It doesn't change the global state - unless there's
> a serious incident. But it breaks resiliency against that incident: it
> kills the guarantee the supervision tree offers you.
>
> I firmly believe that a tool, no matter what it is, should do what the
> user wants, even if it's wrong or can't possibly work. If you cannot do
> what the user wants, don't try to be smart; yell at the user, spam the
> logs if necessary, and fail. But don't do anything the user has not
> explicitly told you to do.
>
> Maybe a dependency manager needs to be smarter than that. In which case
> I would call it a "global state manager". There would be the "current
> state", which starts at "everything down" when the machine boots, and
> the "wanted state", which starts at "everything up"; as long as those
> states are not matched, the global state manager is running, implementing
> retry policies and such, and may change the global state at any time,
> bringing individual services up and down as it sees fit, with the
> ultimate goal of matching the global current state with the global wanted
> state. It could do stuff like exponential backoff so failing services
> would not be "wanted up" all the time; but it would never, ever change
> the global wanted state without an order to do so from the admin.
>
> If you want a dependency manager with online properties, I think this
> is the way to do it.
>
> --
> Laurent
>
>
Received on Tue Jan 06 2015 - 20:30:53 UTC