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