> 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?
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]