> On Jan 6, 2015, at 4:56 PM, Steve Litt <sl...@troubleshooters.com> wrote:
>
> On Tue, 6 Jan 2015 13:17:39 -0800
> Avery Payne <avery.p.pa...@gmail.com> wrote:
>
>> 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?
>
> I thought the way to do the latter was like this:
>
> http://smarden.org/runit/faq.html#depends
>
> If every "upstream" simply declared that his program needs B and C
> running before his program runs, it's easy to translate that into an sv
> start command in the run script.
Normally, with hand written scripts, that would be the case. You cobble
together what is needed and go on your way. But this time things are a little
different. The project I'm doing uses templates - pre-written scripts that
turn the various launch issues into variables while using the same code. This
reduces development time and bugs - write the template once, debug it once, and
reuse it over and over.
The idea for dependencies is that I could write something that looks at
symlinks in a directory and if the template finds anything, it starts the
dependency. Otherwise it remains blissfully unaware.
The issue that Laurent is arguing for is that by creating such a framework -
even one as thin and as carefully planned - it shuts out future possibilities
that would handle this correctly at a very high level, without the need to
write or maintain this layout. To accommodate this possibility and to maximize
compatibility, he is arguing to stay with the same "service is unaware of its
surroundings" that have been a part of the design of all the frameworks - let
things fail and make the admin fix it. There is merit to this, not just
because of future expansions, but also because it allows the end user (read:
SysAdmin) the choice of running things. Or long story short, "don't set
policy, let the end user decide". And I agree; I'm a bit old school about
these things and I picked up Linux over a decade ago because I wanted choices.
But from a practical perspective there isn't anything right now that handles
dependencies at a global level. The approach of "minimum knowledge needed and
best effort separation of duty" would give a minimal environment for the time
being. The design is very decentralized and works at a peer level; no service
definition knows anything other than what is linked in its ./needs directory,
and side effects are minimized by trying hard to keep separation of duty.
Because the scripts are distributed and meant to be installed as a whole, I can
kinda get away with this because all of the dependencies are hard coded out of
the box and the assumption is that you won't break something by tinkering with
the links. But of course this runs against the setup that Laurent was
discussing. It's also brittle and that means something is wrong with the
design. It should be flexible.
So for now, I will look at having a minimum implementation that starts things
as needed. But only if the user sets a flag to use that feature. This keeps
the scripts open for the future while giving a minimum functionality today that
is relatively "safe". So you don't get dependency resolution unless you
specifically turn it on. And turning it on comes with caveats. It's not a
perfect solution, it has potential issues, and the user abdicates/delegates
some of their decisions to my scripts. A no-no, to be sure. But again, that's
the user's choice to flip the switch on...
Also keep in mind that I'm bouncing ideas off of him and he is looking at it
from a perspective much different from mine. I'm taking a pragmatic approach
that helps deal with an old situation - the frameworks would be more
usable/adoptable if there was a baseline set of service definitions that
allowed for a wholesale switch over to using them from $(whatever you're using
now). So it's very pragmatic and legacy and "old school" for desktops and
servers, and that's something still needed because we still have those being
used everywhere. It's basically a way to grandfather the frameworks in using
the current technology by providing all of the missing "glue" in the form of
service definitions. And unfortunately dependency resolution is an old issue
that has to be worked out as one of my goals, which is to increase ease of use
so that people want to switch. Short version: it's a stop gap measure to do
what I am doing. And it will mostly work but only if I am very, very careful.
Laurent is (I am guessing) looking at this from an angle that includes mobile
and embedded devices, slim provisioned virtual machines, and how "current"
system demands are driving Init/services. This is all bleeding edge "the
future of tomorrow is now here today" stuff. It's a different viewpoint and
has different goals. So something will always be slightly off between what I
am a doing and what he is doing - he's waaaay far ahead of me, blazing a trail
while I'm fixing up holes in the "here and now". But it is still important for
me to look into the future and realize where things are going. Nothing is
forever and things change. So I need to be prepared.
Hopefully that clears the air a bit with regard to why I am asking and
Laurent's answers. And my apologies in advance to Laurent if I mis-spoke of
his intentions. This is all provided to you based on my current views at this
point in time.
