Re: thoughts on rudimentary dependency handling

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Tue, 6 Jan 2015 13:17:39 -0800

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

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?

For some, the first choice, which is to immediately fail, is perfectly
fine. I can agree to that, and I understand the "why" of it, and it makes
sense. But in other use cases, you'll have users that aren't looking at
this chain of details. They asked for A to be up, why do they need to
bring up B, oh look there's C too...things suddenly look "broken", even
though they aren't. I'm caught between making sure the script comes up,
and doing the right thing consistently.

I can certainly make the scripts "naive" of each other and not start
anything at all...and leave everything up to the administrator to figure
out how to get things working. Currently this is how the majority of them
are done, and it wouldn't take much to change the rest to match this
behavior.

It's also occurred to me that instead of making the "dependency feature" a
requirement, I can make it optional. It could be a feature that you choose
to activate by setting a file or environment variable. Without the
setting, you would get the default behavior you are wanting to see, with no
dependency support; this would be the default "out of the box" experience.
With the setting, you get the automatic start-up that I think people will
want. So the choice is back with the user, and they can decide. That
actually might be the way to handle this, and both parties - the ones that
want full control and visibility, and the ones after ease of use - will get
what they want. On the one hand I can assure that you will get working
scripts, because scripts that have dependencies can be made to work that
way. On the other hand, if you want strict behavior, that is assured as
well.

The only drawback is you can't get both because of the limitations of the
environment that I am in.
Received on Tue Jan 06 2015 - 21:17:39 UTC