> * Andreas Ericsson [2008-08-07 10:32]:
>> Holger Weiss wrote:
>>> Nagios implements a basic design decision I never quite understood: the
>>> distinction between hosts and services. This distinction seems to add
>>> quite a lot of complexity, such as duplicated code, four different types
>>> of dependencies (parents, host dependencies, service dependencies, and
>>> the implicit service->host dependencies), and so on. I don't really see
>>> the gain over simply dealing with arbitrary "objects" and dependencies
>>> between them, which would reduce complexity and provide more flexibility
>>> (such as the possibility to let some service depend on a host it's not
>>> running on, or the other way round).
>>>
>>> Note that I don't doubt the usefulness of syntactic configuration sugar,
>>> such as the implicit service->host dependencies or the nice and simple
>>> way of mapping the network topology using the "parents" directive. The
>>> thing I don't really understand is why Nagios distinguishes hosts from
>>> services internally (outside the configuration parser). However, I may
>>> well be overlooking something, so I figured I'd ask what it is
>>>
>>> In any case, giving up such basic distinction would of course require
>>> dramatic changes to Nagios' core, I'm not seriously suggesting to do
>>> something like that anytime soon (so this posting probably isn't very
>>> constructive, sorry). I'm just asking out of curiosity.
>> I believe it originated from the fact that object dependencies originally
>> consisted almost solely of the implicit service->host dependencies, which
>> came naturally from just thinking about the network in the first place.
>>
>> Anyway, I'm not convinced that re-arranging the dependency stuff will make
>> things any easier. It's not exactly hard to do it properly in the nagios
>> core today, and I'm having trouble imagining a simple enough config syntax
>> without the host->parent dependency stuff. Have you thought anything about
>> that? If so, what's your suggestion?
>
> I wouldn't want to give up stuff like the "parents" directive or
> implicit service->host dependencies. While I can imagine a syntax which
> would give the user more control over their semantics, increasing the
> user's flexibility isn't really my main point. My question is why
> hosts, services, and the various dependency types are handled separately
> in Nagios' core, as opposed to them just being syntactic sugar which is
> resolved into generic objects and dependencies by the configuration
> parser.
>
> This question first came to my mind while stumbling over the issues with
> Nagios 2.x's host check logic and some problems with host dependencies.
> While thinking about how they should be fixed, I thought that the
> service check and dependency logic already works quite well, and as I
> couldn't really see the inherent difference of host and service objects,
> I thought about whether the separate logic for hosts could maybe just be
> dropped in favour of a generic logic for all monitored objects and their
> dependencies. (IIRC, there even existed some project which suggested to
> avoid host checks by replacing them with service checks/dependencies
> entirely?) Anyway, with Nagios 3.x, these issues are mostly solved, so
> if that would've been the first Nagios release I used, I maybe would
> never have thought about it
>
> However, my (naive?) thought would still be that dealing with generic
> objects and dependencies between them could significantly reduce
> complexity and duplication of code. Nagios' core includes loads of
> host_foo() and service_foo() functions which do similar stuff (or
> different stuff, but I've yet to see a case where I really understand
> why the difference is necessary), and it includes separate code for the
> different dependency types.
>
> To give a concrete example of a problem I still have with Nagios 3.x
> which gives me the feeling that these distinctions sometimes complicate
> things unnecessarily:
>
> We use separate host definitions for separate
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]